HttpSessionBindingListener ClassLoader

[Aaron Mulder]

I'ts been brought to my attention that a
HttpSessionBindingListener is being called with an unexpected thread
context ClassLoader when the session expires.  That interface is used to
detect when object are bound or unbound from a session, and the developer
was attempting to perform an EJB call when the object was unbound.  
However, in Tomcat 3.3.1, the EJB classes are not available when the call
comes in due to a session timeout, because the TCCL is not set to the
appropriate application CL.
Does anyone have any thoughts on the appropriate behavior here?  
Would it be unreasonable to set the TCCL to the application CL when 
calling a HttpSessionBindingListener in the timeout case?  If not, I'll 
file a bug report.
Also, I'm not sure whether this is an issue with the 4.x/5.x 
releases.

Thanks,
Aaron


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Fooling Javac

[Aaron Mulder]

So I'm not going to claim this is portable, but shouldn't it be
possible to provide a different implementation of java.io.FileSystem that
reads files from the current ClassLoader and writes them to a buffer in
memory?  I'm assuming that javac uses java.io.File (anyone know?), so this
would let you compile JSPs without constructing an external environment
for them, or writing the source code or class file to the filesystem.
The problem is that FileSystem is not public, and the method to 
get the current one is native, so you'd have to hack the rt.jar to get 
this to work.  But it might be an interesting experiment to see if it even 
makes a noticeable difference.

Aaron


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [half-off-topic] Java Compilers

[Aaron Mulder]

On Thu, 4 Oct 2001, Deacon Marcus wrote:
> Could you give me url please?

http://java.sun.com/

(Go to the search box in the upper right and put in "dynamic event
listeners".  It's the first hit.  There's now a "new" article and an "old"
article - you want the old one.)

Aaron

RE: [half-off-topic] Java Compilers

[Aaron Mulder]

If you haven't seen it already, there's an article on the Swing
Connection on creating dynamic event listeners or some such which seems to
have been the basis for the Dynamic Proxy support in JDK 1.3.  It has
source code for generating classes on the fly that implement arbitrary
interfaces, including some generic routines for writing useful bits of
bytecode.  If your goals are limited enough in scope, you may want to skip
the source code and just spew out bytecode directly based on the XML file
you're reading.
Also, I have JDK 1.2 implementation of Dynamic Proxies that you're
welcome to look at, based on the aforementioned article.

Aaron

On Thu, 4 Oct 2001, Deacon Marcus wrote:
> Hi,
>
> > From: Dmitri Colebatch [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, October 04, 2001 2:35 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: [half-off-topic] Java Compilers
> >
> >
> > Hi,
> >
> > On Thu, 4 Oct 2001, Deacon Marcus wrote:
> >
> > > There would be two classes, CompileUnit and CompileContext.
> > > First, you create a CompileContext, initialize it with working dir and
> > > classpath, then you create CompileUnit, initialize it with
> > CompileContext
> > > and a .java file. Then, you can call .prepare() or .compile()
> > to compile the
> > > file, and .newInstance() to create an instance or .getClass()
> > to get Class.
> > > Or you could use Class.forName(), since in most cases CompileContext's
> > > classpath would be active classpath.
> > so you're talking about generating java source code, and compiling it on
> > the fly?
>
> Exactly.
> I'm coding it right now - looks like CompileContext is enough - I'll post
> when I finish of course.
>
> > > I'm sure you see the similarity to .JSP now.
> > if my interpretation is correct, yes (o:
> >
> > > While it may seem basic, having API for this wouldn't hurt.
> > > Possible scenario:
> > > Supponse, there's some kind of mail server with *extremely* complicated
> > > rule-set in form of 200kb+ xml. Why not take it, convert it into .java
> > > implementing some interface, convert it to java source with
> > hundreds if not
> > > more ifs and cases, and load it as compiled code.
> > > What I need: since JDK 1.4b2, tools.jar just isn't what it used
> > to be... so
> > > I need some kind of 100% java java compiler. And, I have no
> > idea where to
> > > search for one. Of course, there's dozens, but it must be both
> > stable and
> > > compatible with JDK 1.1 - 1.4.
> > Short of searching google, which I'm sure you're already doing I cant help
> > you there.  What I can suggest though, is for source code generation, a
> > project called Jenesis (http://www.inxar.org) which provides a nice API
> > based on the Java Language spec.
>
> Generating source is out of scope of this project.
> I need it mainly for the complicated configs etc - no point in generating
> structure out of xml which is then analyzed everytime when you can compile
> it into bytecode. I'm sure it's possible to do xml-config to java-source
> transformation in xsl, but I don't like it personally, so I'll leave it to
> someone else.
>
> > cheers
> > dim
>
> Greetings, deacon Marcus
> ~
> HELP STARVING JAVA PROGRAMMER: If you need cheap and reliable JSP hosting,
> please contact [EMAIL PROTECTED] (from 12$/m for 50mb WWW + 20mb mail)
>

Re: Does the beta Tomcat 4 support multiple TLD files in a jar?

[Aaron Mulder]

On Sat, 19 May 2001, Jayson Falkner wrote:
> I assume it does. If so what is the correct way to use this functionality? I
> have been having little luck trying and can't find the answer documented.
>
> Here is a little insight on what I was attempting. The JAR has all of the
> class files in their correct directories along with a TLD in the META-INF
> directory named "exampleTags.tld".
>
> exampleTags.tld has the uri element set with the value "/exampleTags.tld".
>
> ...
> 
>   ...
>   /exampleTags.tld
> 

Well, first it shouldn't be just plain "uri":


/myPRlibrary
/WEB-INF/tlds/PRlibrary_1_4.tld


And second, what are you using for the taglib-location?  That's
how it would locate the .tld file.  If you're not using one, perhaps you
need to prefix the URI with META-INF/ since all the TLDs are required to
be in the META-INF directory of the packaged JAR.

Aaron

> I am trying the following with a JSP.
> ---
> <%@ taglib prefix="e" uri="/exampleTags.tld" %>
> Here is the example tag output: 
> ---
> But a servlet exception error message keeps popping up.
>
> org.apache.jasper.JasperException: File "/exampleTags.tld" not found
> ...
>
>
> Anyone had this before? Advice would be appreciated.
>
> Jayson Falkner
> V.P./CTO, Amberjack Software LLC
> [EMAIL PROTECTED]
> www.jspinsider.com
>
>

Re: Deployment Descriptor Editor

[Aaron Mulder]

On Fri, 16 Mar 2001, Remy Maucherat wrote:
> Is it the same UI that is used in OpenEJB ?
>
> Also, can it edit the security constraints ?

Sorry, I've been out of touch for a while.

Yes, and yes.  It has editors for everything in the servlet 2.2
deployment desriptor, including security constraints.  For security
constraints, you still have to enter the URL pattern manually, but it
knows about the available transport guarantees, HTTP methods, and security
roles so you just select those from a list.
As for OpenEJB, I hadn't updated the version there until tonight,
but it is the same tool.  So in addition to web app WARs, you can edit EJB
JARs including the standard DD and the extensions for JBoss 2.0 and
OpenEJB 1.1, and you can edit JCA RARs including the standard DD and the
extensions for OpenEJB 1.1.  It uses a plugin architecture so there are
separate plugins for J2EE 1.2, OpenEJB, JBoss, etc. and you load the
plugins you're interested in and then when you open a J2EE archive or
directory it loads the data and editor screens for the plugins you've
selected (or the ones that care about that archive type, at any rate).
I'm wondering if Tomcat won't eventually have a separate custom DD
for WARs (like WEB-INF/tomcat-web.xml or whatever), in which case we'd
want to create a Tomcat plugin in addition to the standard servlet spec.
In any case, I did finally manage a downloadable version, though
I'm still working on setting up a box for anonymous CVS 'n stuff.

Aaron

http://www.mearaworks.com/jedi-1_0b4.zip
http://www.mearaworks.com/jedi-1_0b4-src.zip

Deployment Descriptor Editor

[Aaron Mulder]

I have a GUI for editing deployment descriptors in-place in J2EE
archives or directories laid out like archives (so far EJB 1.1 JARs,
Servlet 2.2 WARs, JCA 1.0 RARs).  It's open-source under the X license,
though for the few weeks without a home on the web.  I wonder if you'd be
interested in including a binary with Tomcat (the 3.x branch for now,
since it doesn't support 2.3 yet).  If anyone's interested in trying it
out, I can send you a copy.

Aaron

Re: Implementation in 4.0.b1

[Aaron Mulder]

I'm a little confused by all of the discussion around this.
Acoording to the spec, the  is supposed to have the name of
an EJB deployed in the same application unit.  In other words, no JNDI
stuff, no factories, just a name.  "MyBean", or whatever.
If Tomcat wants you to put JNDI stuff in there, isn't that an
abuse of the spec?  Shouldn't Tomcat be using a separate server-specific
deployment descriptor to provide the extra information to reference beans
that are in a different application (i.e. those that require cusotm JNDI
settings)?

Aaron

On Fri, 9 Mar 2001 [EMAIL PROTECTED] wrote:
> Weining Qi writes:
>
> > if you are running tomcat 3.x in the same window (tomcat run), look at the
> > feedback from tomcat when call the ejb that way, you can see that tomcat
> > does not recognize the namespace "java:com/env/" for calling ejb as
>   The name is "java:comp/ejb"  NOT --.
>   And yes tomcat does recognize it
>   Because it is defined in web.xml as shown in the snip.
>
> > the sun j2ee specification v1.3. you should call ejb directly by its jndi
> > name, which you gave when you deployed it.
> I tried that, it does not work.  I get "NamingException".
> Note: the EJB is deployed in a different machine than tomcat.
> When I try to open the context to that machine directly from a servlet in
> tomcat, I get:
> javax.naming.NoInitialContextException: Cannot instantiate class:
> org.jnp.interfaces.NamingContextFactory.  Root exception is
> java.lang.ClassCastException: org.jnp.interfaces.NamingContextFactory
> at
> javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:659)
> at
> javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:250)
> at javax.naming.InitialContext.init(InitialContext.java:226)
> at javax.naming.InitialContext.(InitialContext.java:202)
> at SimpleServlet.printContextInfo(SimpleServlet.java:168)
> at SimpleServlet.doIt(SimpleServlet.java:99)
> at SimpleServlet.doGet(SimpleServlet.java:30)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> at
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:573)
> at
> 
>org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:321)
> at
> 
>org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:236)
> at
> org.apache.catalina.servlets.InvokerServlet.serveRequest(InvokerServlet.java:386)
> at
> org.apache.catalina.servlets.InvokerServlet.doGet(InvokerServlet.java:144)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> at
> 
>org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
> at filters.ExampleFilter.doFilter(ExampleFilter.java:140)
> at
> 
>org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:180)
> at filters.ExampleFilter.doFilter(ExampleFilter.java:140)
> at
> 
>org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:180)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:251)
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:196)
> at org.apache.catalina.valves.ValveBase.invokeNext(ValveBase.java:242)
> at
> 
>org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:464)
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:975)
> at
> org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2041)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161)
> at org.apache.catalina.valves.ValveBase.invokeNext(ValveBase.java:242)
> at
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:414)
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:975)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:159)
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:977)
> at
> org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:818)
> at
> org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:897)
> at java.lang.Thread.run(Thread.java:484)
>
> YET: this same code works when I run it from a standalone Java application.
> I believe that tomcat's InitialContext() is preventing the remote
> connection from being established.
>
> >
> > Weining
> > 
> > Weining Qi
> > RabobankICT and Info.nl, Amsterdam
> > IPO, TU/e, Eindhoven, The Netherlands
> > http://weining.n3.net/
> > Tel: +31.628161183
> >
> > - Original Message -
> > From:

Re: Tomcat 4 unpacking of WAR files behavior

[Aaron Mulder]

On Fri, 2 Mar 2001, Craig R. McClanahan wrote:
> > Yes sure. I think the best would be not to unpack the WARs (it's a lot
> > cleaner).
>
> +1, as long as we can keep performance reasonable.

Well, memory's cheap.  You can always just read the whole WAR in.
Then you'll get great performance.  :)
As a middle ground, it probably wouldn't be too horrible to
implement a ClassLoader that cached frequently-accessed resources from
the WAR.

Aaron


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [PATCH] CatalinaBlock.java

[Aaron Mulder]

It's always going to be the case that the Avalon and Tomcat releases 
don't sync up perfectly.  How would you feel about making any Tomcat 
changes necessary to support the Avalon patch, but maintaining the 
Avalon block itself outside of the main Tomcat 4.0 module?  That way the 
Avalon support could be updated independently for new releases of Avalon 
*or* Tomcat.

Aaron

Remy Maucherat wrote:

> I'm -1 on applying the Avalon patch in the 4.0 tree.
> The rationale is :
> - Avalon isn't ready yet. It's still in alpha stage, and I fear there may be
> API changes in the pipeline.
> - TC 4.0 should be out before Avalon. If Avalon 3.1 evolves *after* TC 4.0
> is released, this would break the wrapper included in TC 4.0 and make it
> incompatible with the Avalon 3.1 production release, which would more or
> less force us to do a TC maintenance release.
> 
> For these reasons, I'd like to see an official Avalon wrapper introduced in
> Tomcat 4.1, but not in Tomcat 4.0.
> I also propose to remove the current Avalon wrapper from the Tomcat 4.0
> repository, to avoid the maintenance related issues.
> 
> The 4.1 repository should be recreated very soon, since TC 4.0 has gone back
> into feature freeze mode (but we want to fix the sealing violation problems
> reported by many people before).


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: The case of the disappearing webapps...

[Aaron Mulder]

Probably caused by using a URLClassLoader.  On Windows, it locks
JAR files and never lets go (I've seen this).  Also, there was a rumor
that it caches JAR files so if you redeploy an updated app with a new JAR
file with the same name as the old one it will still use the old one, or
something like that.  I haven't tried to confirm that part of it.
The only solution I've found is to implement a new ClassLoader for
JAR files, because if you're very careful with your JarFile objects and
streams you can definitely avoid this on Windows.  I haven't seen that
problem on Linux.

Aaron

On Fri, 19 Jan 2001, David Weinrich wrote:
> Ok, I think I have found the problem, and I am guessing the following is
> happening:
>
> 19-Jan-2001 15:10:44 StandardHost[localhost]: Undeploying web application at
> context path /struts-test
> 19-Jan-2001 15:10:44 StandardHost[localhost]: Removing expanded directory
> c:\java\tomcat-4.1\webapps\struts-test
>
>  * the container is trying to undeploy the application
>( hey I didn't even know this happened ;) because it was
>deployed from a .war file.
>
> 19-Jan-2001 15:10:44 HostConfig[localhost] Error undeploying web application
> at context path /struts-test
> java.io.IOException: Cannot delete file
> c:\java\tomcat-4.1\webapps\struts-test\WEB-INF\lib\struts.jar
>  at org.apache.catalina.core.StandardHost.remove(StandardHost.java:794)
>
>  * Win2k is not allowing the container to delete a library file
>that it thinks is currently in use ( struts.jar in this case ).
>
> 19-Jan-2001 15:11:06 StandardHost[localhost]: Deploying web application at
> context path /struts-test from URL
> file:C:\java\tomcat-4.1\webapps\struts-test
>
>
>   * catalina finds the struts-test directory and doesn't re-deploy the
> application from the .war file.
>
> If I shutdown, delete the expanded directories, and restart, the .war files
> deploy normally:
>
> 19-Jan-2001 15:56:26 StandardHost[localhost]: Recording expanded app at path
> /struts-test
> 19-Jan-2001 15:56:26 StandardHost[localhost]: Deploying web application at
> context path /struts-upload from URL
> jar:file:C:\java\tomcat-4.1\webapps\struts-upload.war!/
> 19-Jan-2001 15:56:26 StandardHost[localhost]:
> expand(jar:file:C:\java\tomcat-4.1\webapps\struts-upload.war!/)
> 19-Jan-2001 15:56:26 StandardHost[localhost]:   Proposed directory name:
> struts-upload
> ...
>
> I will try to dig into this more later tonight/this weekend. Any
> further hints/ideas would be appreciated :)
>
> David Weinrich
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: TC4's classloader choking on xerces.jar (maybe)

[Aaron Mulder]

On Wed, 17 Jan 2001, Craig R. McClanahan wrote:
> Consider the following scenario - I put a copy of the Postgres JDBC
> driver (just to show that it's not specific to xml parsers :-) in my
> shared library directory, because lots of my apps need it.  But, one
> of my webapps needs a different version of the Postgres driver,
> because it depends on a new feature that was implemented in a later
> version.  So, I put the new driver file in the WEB-INF/lib directory
> of my webapp, and install it in Tomcat.
>
> Under Tomcat 3.2, the newer driver is ignored (because it's got the
> same class names).  Under Tomcat 4.0, the newer driver is respected
> for that webap -- all others continue to use the shared one.

There is still the "sealing" issue, right?  Certain libraries
cannot be loaded in more than one ClassLoader, and are marked as "sealed"
in the Manifest.  If you put one in the Tomcat lib and another in the
webapp lib, you'll get cryptic "Sealing Violation" exceptions.  I think
some of the XML JARs do this (JAXP, perhaps?).
I don't have a full understanding of this, though.  Perhaps it
only breaks if loaded more than once in serial ClassLoaders not parallel
ones.  But I think tomcat's lib is sill in serial with webapp lib, right?

Aaron


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: [MY_OPINION] Tomcat 3.x

[Aaron Mulder]

On Mon, 18 Dec 2000, Henri Gomez wrote:
> The users will decide. Be fair, let them evaluate TC 3.3.

Speaking as a user, this doesn't make sense.  It's fine to compare
two different products, but it doesn't make any sense to compare two
different versions of the same product that are undergoing simultaneous
release cycles.  Especially when you ask the list which you should be
looking at, and you get one answer: "V3.3 because the architecture is
better and V4 is an unstable rewrite," followed immediately by "V4 because
the architecture is better and V3.3 is an unstable rewrite."  The
immediate reaction to which is, "if the *developers* can't even figure it
out, I'm going elsewhere."
I'm not saying you should cut off all 3.3 development, I just
think it should fork and use a name other than "Tomcat".  Maybe "xTomcat".
:)

Aaron

Re: jboss on tomcat update

[Aaron Mulder]

For what it's worth...

-- Forwarded message --
Date: Mon, 30 Oct 2000 19:03:39 -0500
From: Free Software Foundation <[EMAIL PROTECTED]>
To: Aaron Mulder <[EMAIL PROTECTED]>
Subject: Re: Java, GPL, & APL

Aaron Mulder wrote:

>   Okay, I've heard too many opinions on the GPL, so I'm taking it to 
> the source.  I will discuss this in general terms if it's OK with you.
>
>   There exist two open-source products.  One uses an Apache license.
> One uses a GPL license.  They are complimentary products - the capabilites
> of both together are greater than that of either alone.  They can be run
> totally independently, communicating over the network, but the performance
> is not great.  They can also be run together, in the same Java VM, and the
> performance is much better.  The GPL product has included some code that
> configures and launches the APL product.  It directly references Java  
> classes (such as the startup class) that are part of the APL product.
> This is what allows you to run them together within one VM.  The APL   
> product does not ever reference the GPL code directly - only through the
> standard interfaces defined by Sun in one of the javax.* packages.  After
> the startup sequence, the GPL product never refers to the APL code
> directly at all (essentially, the APL product is a client of the GPL
> product).
>   So the questions are:
>
> 1) Is it legal for the APL product to work with the GPL product through
> the standard interfaces defined by Sun in the javax.* packages?  We
> suspect yes, since this is a standard and the APL program never reaches
> "through" those standard interfaces to deal directly with the GPL code.

It appears that you combine the APL'ed software with the GPL'ed software to
form a larger program.  This is not permitted, since the APL is incompatible
with the GPL.
 
> 2) Is it legal for the GPL product to directly reference APL classes to
> configure and start the APL product?

No, that is not legal, because you are combining the two programs to form a
larger program.

 
> 2b) If there is a problem with this, is there any way to configure and
> start the two products in the same VM?

Not if they make calls to each other.  You'll need to get the license of one
or the other changed to a dual license---the disjunction of the GPL and the
APL.

 
> 3) Would it be appropriate to package the GPL product and "glue
> code" (startup and configuration for APL product) together, and leave the
> APL product separate?

We believe this is legally the same as distributing them together, and thus,
is not permitted.


> 4) Would it be legal to package everything together, and create one
> combined download that "out-of-the-box" runs both products together?  This
> is the subject of much debate.

That is not permitted since the APL is incompatible with the GPL.


>   So it's not clear whether the phrase "contains or is derived
> from" would apply to this single unified package.  

We argue that it definitely does, when you combine them together to form a
larger program.

-- 
Bradley M. Kuhn
Free Software Foundation |  Phone: +1-617-542-5942
59 Temple Place, Suite 330   |  Fax:   +1-617-542-2652
Boston, MA 02111-1307  USA   |  Web:   http://www.gnu.org


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [jBoss-Dev] Re: jboss on tomcat update

[Aaron Mulder]

(EVERYONE: Please, PLEASE, leave the threats at the door.  Honestly,
raising the general level of antagonism is not getting us anywhere!)

On Mon, 30 Oct 2000, marc fleury wrote:
> Aaron the bundling of APIs (JSP, EJB) that don't work together (JSP doesnt
> rely on EJB, and EJB doesnt rely on JSP) is PURE aggregation.  It is useful
> for the beans.  There is never CMD in the aggregate work.
> 
> I am sorry but the line in the license is extremelly clear (yes specially 2b
> rickard).

Marc, nothing in this entire discussion has convinced me that the
GPL is "extremely clear" on anything - in fact, I find that quite the
opposite to be true.  No matter how many times you state "that is not
true" or "the text is clear" it does not convince anyone else of anything.  
Perhaps you could substantiate your arguments slightly more?
You seem to think that containment should be strictly interpreted
as "a line of code from program X is placed in program Y".  However, that
is not clarified anywhere in the GPL.  There is nothing in the wording of
the license that leads me to believe that "containment" refers to "lines
of source code" as opposed to "entire products".  What leads you to this
conclusion?
And once again, the deciding factor is not what Marc Fleury
thinks, or even what the jBoss Board thinks, it is what the users,
observers, and lawyers think - what the "community" thinks.  After all,
nowhere in the license does it state that the composition of and/or
opinions of the board will never change.
Don't you find it just a little bit worrisome that no one who has
spoken up from any of the Apache projects believes that jBoss can be
legally integrated with Tomcat or Avalon?  Even if every single one of
them is wrong, don't you think this unanimous opposition from the groups
we are trying to work with is going to cause problems with the adoption of
the integrated work?

Aaron

> In other words a J2EE server is pure "API together bundled" but I don't see
> the other API from my code, and I never have to add anything to anyone of
> them.  All CMD work is GPL'ed (MBeans).
> 
> Same mistake with JMX, it is VERY ignorant to claim linking -> GPL.  so GPL
> work does run on windows, because windows is not CMD work of GPL...
> 
> this is getting tiring...
> 
> JMX is not CMD work of jboss...
> 
> marc
> 
> 
> |-Original Message-
> |From: [EMAIL PROTECTED]
> |[mailto:[EMAIL PROTECTED]]On Behalf Of Aaron Mulder
> |Sent: Monday, October 30, 2000 6:49 AM
> |To: jBoss Developer
> |Subject: Re: [jBoss-Dev] Re: jboss on tomcat update
> |
> |
> |On Mon, 30 Oct 2000, Ole Husgaard wrote:
> |> Before we go to such drastic steps as changing the license,
> |> we should find out exactly what is the problem with the
> |> license we have now. I've seen many flames and much hearsay,
> |> and a lot of crying from both sides, but from facts and
> |> valid arguments I have only been able to identify three
> |> "problems":
> |>
> |> 1) jBoss cannot include the Tomcat code and distribute
> |>the combination without breaking the APL license of
> |>Tomcat.
> |> 2) Tomcat cannot include the jBoss code and distribute
> |>the combination without breaking the GPL license of
> |>jBoss.
> |> 3) Someone (forgot who) refuses to add the jBoss code
> |>to their tree because they have a problem with the
> |>GPL license.
> |
> | I think we need to add
> |
> |  4) It has been debated whether it is legal for jBoss to include
> | packages such as JMX which are neither GPL nor "safe"
> | operating system code
> |
> |> In all three cases my opinion is "So what?".
> |
> | We're all entitled to an opinion.
> |
> |> In the two first cases: These two programs can
> |> easily be distributed seperately.
> |
> | I think the usefulness of a J2EE server is dramatically
> |higher than the usefulness of an EJB server.  Thus I think it's
> |safe to say that it's a "good thing" to be able to integrate
> |jBoss and Tomcat.  If you insist on keeping them separate, you
> |sacrifice performance (I don't think you could rationally claim
> |they're totally separate product when you distribute same-VM
> |integration code that deals with both directly - unless that's
> |yet another package), distribution (2 packages?  How silly is
> |that?), and market (Let's see, I could have one integrated and
> |fully-tested product [Weblogic], or two completely separate
> |products that not even that authors believe can be safely run
> |together...)
> |

Re: [jBoss-Dev] Re: jboss on tomcat update

[Aaron Mulder]

On Mon, 30 Oct 2000, Rickard [iso-8859-1] Öberg wrote:
> Dear all,
> 
> I've read through the GPL license, and I'm not a legal expert but from
> what I can see paragraph 2b is a killer. For example, I cannot see how
> XO3 can redistribute jBoss with Tomcat and reasonably call it "mere
> aggregation" (i.e. our JMX integration is not "mere aggregation", it is
> much more than that), thus OpenJoda needs to "be licensed as a whole at
> no charge to all third parties under the terms of this License." Which
> breaks Tomcat's license, so it's out of the question.
> 
> After listening to Marc's and all others arguments back and forth I have
> the following thoughts (right or wrong, here they are):
> * GPL paragraph 2b is a killer, and I cannot see how we can
> bundle/integrate Tomcat without having to apply GPL to the whole
> shebang. Sorry Marc, I just don't see it. The clause does not say "mere
> aggregation in a Program" (which is what we do). It says "mere
> aggregation of another work not based on the Program with the Program
> (or with a work based on the Program) on a volume of a storage or
> distribution medium", which is a completely different thing, closer to
> Oles reference to RedHat CD's (BTW, yes I know I'm violating GPL
> copyright by quoting it. So sue me)
> * *Regardless* of whether we can do this or not, we can't "win". I don't
> really care how *we* interpret GPL, and from what it seems our
> interpretation is the loosest ever. It will do two things: 
> 1) GPL hardcores will, pretty much, hate jBoss. Slashdot, here we come..
> 2) "Suits" will stay away from jBoss ANYWAY, because it uses GPL. "So,
> we can use it? Nah, my left foot says no, so that's it. I'm going with
> OpenEJB. BSD gives me a fuzzy feeling". I don't care if it's rational or
> not; there you have it. 
> 
> To me the solution seems clear. IMHO jBoss is not a "baby" anymore. We
> do not have anything to gain by doing a crusade with GPL. We may not be
> exactly where we want just yet (i.e. Project Game Over is not done), but
> we sure are "enough" along the way to getting there. I may be wrong, but
> that's my gut feeling anyway :-) 
> 
> So, for it to grow to the heights we want it if changing the license to
> APL or MPL or BSD, or whatever makes sense (just not GPL), is what it
> takes, then that's the way to go. IMHO of course.

Amen.  I agree 100%.

Aaron


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jBoss-Dev] Re: jboss on tomcat update

[Aaron Mulder]

On Sun, 29 Oct 2000, Dan OConnor wrote:
> In no way is the choice of license intended to prevent aggregation 
> with Tomcat, nor to the best of my knowledge does the board--or 
> the jBoss community in general--currently believe that this is the 
> result. This sort of opinion is not like source code; we can't compile 
> it and see it run (or not). I'm sorry about that. But there it is.

Do you acknowledge that a number of people have a different
opinion?  If so, do you think their opinions count?  That is, will you be
happy if everyone on the jBoss board believes that jBoss can be legally
integrated with Tomcat, or will you be happy if everyone in the world
believes that jBoss can be legally integrated with Tomcat?
In my case, it is not a case of what I believe, but what my
company's clients believe, and unfortunately they do not see eye to eye
with the jBoss board.  Does that matter to you?  It matters to me, because
it matters to the people who decide what I will be paid to work on.  :)
I think we should do whatever we can to make jBoss universally
acceptable.  Because I want everyone in the universe to be able to choose
to use it, on the basis of its features not on the basis of its license.

Aaron



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [jBoss-Dev] Re: jboss on tomcat update

[Aaron Mulder]

On Sat, 28 Oct 2000, Jon Stevens wrote:
> on 10/28/2000 4:06 PM, "marc fleury" <[EMAIL PROTECTED]> wrote:
> > Indeed if the Avalon guy puts jBoss code in his tree and "contains" our work
> > in his work then yeah.. that needs to be GPL.
> Bingo. So, this is something that is a major problem for me.

This is truly unfortunate.  There are definitely ares of code that
could be shared - that *should* be shared, such as logging, dynamic
proxies, thread pools, and so on.  It's too bad that it doesn't happen
until a javax package is available...  Particularly since those are *not*
open source (well, under a much more restrictive license, anyway).

On Sat, 28 Oct 2000, marc fleury wrote:
> |2.b.) You must cause any work that you distribute or publish, that in
> |whole or in part contains or is derived from the Program or any part
> |thereof, to be licensed as a whole at no charge to all third parties under
> |the terms of this License.
>
> again, "work that contains the Program" is code that "contains" physically 
> the Program (maybe thinking import in programming terms can help).

What can I say?  I agree that this is a reasonable interpretation.  
But I don't think it's the only interpretation, and I'm not sure it's even
the interpretation intended by the authors.  There's another section that
specifically allows distribution of GPL and non-GPL programs on the same
medium (Linux distributions), and that passage would be redundant if this
passage reads as you suggest.
I think it would definitely be safe to download a set of RPMs (one
per product) and then install them all and configure them to point to each
other (using network protocols, standard interfaces, etc.), but I think
it's very questionable whether you can put them in a single pre-configured
package.
The problem is, I'm in a situation where (to quote "Ronin"),
"Whenever there's a doubt, there is no doubt."  Whatever you say, I
haven't heard anything that convinces me that the interpretation is clear
- I can easily see both sides of the disagreement.  I suspect the only way
for this to ultimately be resolved is to take it to a lawyer and/or RMS.  
Any volunteers?  :)

Overall, the most unfortunate thing here is that I don't believe
either party is trying to lock out code from the other.  But the fact that
the licenses are not compatible means that one group or the other has to
change licenses in order to enable true sharing of code, which is one of
the greatest promises of open source.  And it doesn't sound like either
party is willing.

Aaron

RE: [jBoss-Dev] Re: jboss on tomcat update

[Aaron Mulder]

Marc,
I'm on your side.  I would *really* like to be able to use jBoss.  
However:

Please interpret the following passage of the GPL, and tell us how
it applies to an app server based on software like Apache, Tomcat, Avalon,
Castor, Tyrex, PostgreSQL, and jBoss.  Specifically, imagine I want to
make available a single download for a full open-source J2EE app server.  
Do you think it is possible to include jBoss with non-GPL packages?

2.b.) You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any part
thereof, to be licensed as a whole at no charge to all third parties under
the terms of this License.

Thanks,
Aaron

On Sat, 28 Oct 2000, marc fleury wrote:
> Ok,
> 
> I am sorry, I should actually provide some information.
> 
> We use the GPL to protect the kernel.  The virality of the GPL applies to
> the "derived work" or "modified work as a whole" of the kernel.
> 
> Tomcat is not "derived work" of jboss, clearly, wouldn't you say? :). The
> "modified work as a whole" done in jboss to integrate the Tomcat jar is the
> MBean adapter (for JMX), the Tomcat Interceptors (classLoaders), and the
> J2EE deployer that we have developed.  Those are GPL, as per the GPL derived
> work virality.
> 
> The GPL applies to derived work in distribution.  Our distributions are GPL
> kosher.
> Please don't be afraid of it, and feel free to discuss it...
> 
> regards
> 
> marc
> 
> |-Original Message-
> |From: marc fleury [mailto:[EMAIL PROTECTED]]
> |Sent: Friday, October 27, 2000 10:10 PM
> |To: jBoss Developer; [EMAIL PROTECTED];
> |[EMAIL PROTECTED]
> |Subject: RE: [jBoss-Dev] Re: jboss on tomcat update
> |
> |
> || but at the same time, you have a problem with the GPL being
> ||viral so you give exceptions for people to use JBoss. Instead, what you
> ||should do is probably be using the MPL license which will solve your needs
> ||without having to constantly grant exceptions to people.
> |
> |???
> |
> |what 'exceptions'? we never granted 'exceptions'.  Please explain.
> |
> ||It is funny to me how you say that you are integrating our code which I
> ||think is great, but the real issue is that we can't integrate YOUR code
> ||because you choose to use the GPL license.
> |
> |why not?  what exactly prevents you from integrating our work?
> |Please be explicit,
> |
> |let's not work from hearsay and "impressions" of the GPL, the GPL
> |is very explicit.
> |
> |regards
> |
> |marc
> |
> |
> |
> ||
> ||Sigh.
> |
> |
> |
> ||
> ||-jon
> ||
> ||
> ||
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]