Peter Donald wrote:
>
> At 12:50 1/11/00 +0100, you wrote:
> >> but the code to do the loading will.
> >
> >You are talking about jBoss being hardcoded to start
> >Tomcat here?
> >I agree this is a problem, but fixing this problem is
> >IMO not.
> >Now assuming we have already fixed this problem, do
> >you think there would be other problems with having
> >jBoss and Tomcat loaded in the same VM ?
>
> Not even hardcoded - the mechanisms you have now in place or even with some
> changes are just not enough. Tomcat has to be to jBoss what a servlet is to
> a servlet engine. jBoss has to provide a place to run Tomcat or any other
> program with a similar interface.
Don't know Tomcat, so I may be wrong. But:
The place to run Tomcat is a Java VM. The jBoss
code has to provide a way to start Tomcat for
embedded operation in a way that does not create
a license conflict, but once started there is no
direct interaction between these two.
> So you need to define such an interface and make sure it is widely
> implementable. Ie Need a mail server ? then it implements interface. Need a
> directory server --> implement the interface.
Here we need Tomcat, but do we really need a glue
interface and glue code to load it?
Think of a GPLed java program using JDBC. The JDBC
interface is "platform code" that calls the JDBC
implementation. But to get the vendor-specific JDBC
implementation loaded in the VM, a call similar to
Class.forName(myConf.getJDBCImplName()) is used.
You don't think that loading the JDBC implementation
this way will create a conflict between the GPL and
the JDBC implementation license, do you ?
> If you do that then there is no problem.
Great.
> >> >> 3 is violated all the way through jBoss with JAAS, JTA, (EJB ?), JMX,
> >> (JMS?)
> >> >
> >> >Yes. I agree that we must get rid of the violations.
> >>
> >> the question I ask is - Is it possible ?
> >
> >I think it is, but it depends on what is considered
> >"platform code" on the Java platform.
>
> >I guess you are talking about the EJB system classes
> >and interfaces as distributed by Sun in file ejb.jar.
> >These are all in javax.ejb.*, so if javax.* code is
> >considered "platform code" there should be no problem
> >with this.
> >Similar arguments for JTA and JMX.
> >Haven't checked JAAS and JMS, but I would be surprised
> >if they are not also in javax.*.
>
> right but under GNU interpretation this does not hold. Only stuff that are
> downloaded in one package (ie j2ee, j2se, j2me, personaljava etc) is
> considered to be covered by clause 3. The extra extentions (javax.* not
> included in above) is not covered by clause 3.
Seems like we still have a few differences here.
You think that javax.* is not considered "platform code",
while I think it is. We should be able to find out who
are right on this issue.
With respect to the J2EE, J2SE, J2ME etc. "platforms", I
don't buy the argument that these are different platforms.
Let me try to explain: Sun is very concerned that there
must be one and only one Java platform. They are open enough
to allow others to do clean-room implementations of Java,
but are keeping the Java trademark so they can ensure that
other implementations are not called Java unless they accept
it. The usefulness of this was shown in their Microsoft case.
Unfolding the acronyms may help in understanding this:
J2EE is an abreviation of "Java 2 platform, Enterprise
Edition", and J2SE is an abreviation of "Java 2 platform,
Standard Edition". So these are simply different editions of
the same platform.
Sun wants the Java platform to consist of a conforming
JRE and libraries implementing all java.* packages and a
subset of the javax.* packages, or they will _not_ allow
the use of their Java trademark.
> >This is why it is always amended rather than modified.
> >But amending it is also problematic, for reasons
> >already discussed.
> >If possible we should try to avoid amendments.
>
> right - I am not sure that is possible given above (namely extentions are
> not covered by clause 3). So you could continue to make it GPL via
> * designing a special interface that arbitrary services could be launched
> from and then implementing a tomcat service and placing this code in a
> different archive from jBoss code.
> * giving exceptions for all standard java extentions.
For your first item above, I agree that there is a problem
with Tomcat and all other code that is not "platform code".
For your second item above, we have different opinions:
I think that javax.* is "platform code", and thus no
exception is needed.
If I am right about javax.* being "platform code", I think
(but will still have to check) that Tomcat is the _only_
place where we have this problem. When we define a generic
and configurable way of starting an embedded JSP server,
my guess is that Tomcat developers will line up to add code
that will support starting Tomcat our way. (If needed. I am
not sure if a sensible and generic way of starting an
embedded JSP server from jBoss will be so simple that
Tomcat already supports it.)
Best Regards,
Ole Husgaard.
