RE: Tomcat 4.01 classloader problem?

["Marx, Mitchell E (Mitch), ALSVC" <mm...@att.com>]

As it seems a whole lot of people keep coming back to the classloader, I
have a few questions in general.  

1) Tomcat seems to be taking a pretty self-centered view of the world, in
that any libraries it needs must be installed in one of it's pre-designated
directories. Why is that?  I'm guessing for sake of the Tomcat code, not the
Tomcat user.  It also goes against standing practices:

	a) The JAVA_HOME/jre/lib/ext directory for placing JAR files, 
		From what I have read, Tomcat has a problem if things ARE
placed there? (like servlet.jar) 
	b) Oracle JDBC driver is a .zip, not a .jar and not usually
installed "inside" Tomcat
		Yes, I have heard the solution of creating the symbolic
link, but this is clumsy.

2) Can/Should there be a command line option to Tomcat:
	a) boolean to indicate use the CLASSPATH (default to false)
	b) define the classloader (like java.security.manager)
	c) add jar or ZIP files, or directories, to each part of the
classloader (ie. add JDBC driver to common classloader)

I am currently porting my application from WebLogic.  They dropped the whole
CLASSPATH vs weblogic.class.path due to this class loader confusion.  

And I am quite aware of the "If you don't like it, change it" policy; just
trying to feel some people out on the topic.  Perhaps this question is
better served on the tomcat-dev mailing list, but I do still consider myself
a "newbie".

Thanks for listening.

Mitchell Evan Marx        mmarx@att.com
AT&T IP Network Configuration & Provisioning Development


-----Original Message-----
From: Craig R. McClanahan [mailto:craigmcc@apache.org]
Sent: Sunday, December 02, 2001 11:38 PM
To: Tomcat Users List
Subject: Re: Tomcat 4.01 classloader problem? (Craig)


I haven't had a chance to run your test case yet, but I suspect the cause
might be related to a feature allowed in a Servlet 2.3 environment.  From
Servlet 2.3, Section 9.7.2:

   "It is recommended also that the application class loader
    be implemented so that classes and resources packaged within
    the WAR are loaded in preference to classes and resources
    residing in container-wide library JARs."

Tomcat 4 implements this "SHOULD" feature, as will most other Servlet 2.3
implementations.  What it means is that, if you have a class
org.apache.soap.Foo in *both* the web app (under WEB-INF) and in the
shared "lib" directory, Tomcat 4 will load the version from WEB-INF.
Tomcat 3.2 loads the one from "lib" in this scenario.

Applications that intend to be portable across servlet versions need to
recognize this difference in order to operate correctly.  Of course,
you shouldn't have a problem if you only have the classes one place or the
other (and not both).

That being said, I will try your test case when I get a chance, to see if
there is anything else in the logs that might indicate a different
problem.

Craig


On Mon, 26 Nov 2001, Chris Malley wrote:

> Date: Mon, 26 Nov 2001 10:36:40 -0700
> From: Chris Malley <cm...@pixelzoom.com>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: tomcat-user@jakarta.apache.org
> Subject: Tomcat 4.01 classloader problem? (Craig)
>
> Santosh on soap-users@xml.apache.org suggested I post here,
> and ask for Craig.  So if Craig (or anyone else) is listening...
> Help!!
>
> I'm experiencing a problem with SOAP message-style services
> when using Tomcat 4.01.  Santosh suggested that this may be a
> classloader problem in Tomcat 4.01.
>
> I have a very simple SOAP message-style service that demonstrates the
> general problem.  This service echoes whatever is sent to it.  It works
> fine with Tomcat 3.2.3, but is returning a "no signature match" fault
> with Tomcat 4.01.
>
> If I resort to removing
> $CATALINA_HOME/webapps/soap/WEB-INF/classes/org/,
> I can get this service to work.  But I don't understand why,
> and it's clearly an unacceptable hack.
>
> I've attached the following:
>   details.txt    -- detailed problem description
>   echomsg.tar.gz -- Java source, deployment descriptor, Makefile, fault
> details
>
> Any help in correcting/understanding this will be appreciated.
> Sorry for the size of this post, but I'm trying to provide all
> of the details necessary to resolve this.  Thanks,
>
> -Chris
>
> --
> Chris Malley
> PixelZoom, Inc.             Voice: +1.303.494.8849
> 835 Orman Drive             EMail: cmalley@pixelzoom.com
> Boulder CO 80303-2616


--
To unsubscribe:   <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>

--
To unsubscribe:   <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>

RE: Tomcat 4.01 classloader problem?

["Craig R. McClanahan" <cr...@apache.org>]

On Mon, 3 Dec 2001, Marx, Mitchell E (Mitch), ALSVC wrote:

> Date: Mon, 3 Dec 2001 08:19:13 -0500
> From: "Marx, Mitchell E (Mitch), ALSVC" <mm...@att.com>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: Tomcat Users List <to...@jakarta.apache.org>
> Subject: RE: Tomcat 4.01 classloader problem?
>
>
> As it seems a whole lot of people keep coming back to the classloader, I
> have a few questions in general.
>
> 1) Tomcat seems to be taking a pretty self-centered view of the world, in
> that any libraries it needs must be installed in one of it's pre-designated
> directories. Why is that?  I'm guessing for sake of the Tomcat code, not the
> Tomcat user.  It also goes against standing practices:
>
> 	a) The JAVA_HOME/jre/lib/ext directory for placing JAR files,
> 		From what I have read, Tomcat has a problem if things ARE
> placed there? (like servlet.jar)
> 	b) Oracle JDBC driver is a .zip, not a .jar and not usually
> installed "inside" Tomcat

Tell that one to Oracle -- they persist in doing the wrong thing.

> 		Yes, I have heard the solution of creating the symbolic
> link, but this is clumsy.
>

First, historical experience with many years of Apache JServ and Tomcat
users shows that using either CLASSPATH or the Java System Extensions
directory ($JAVA_HOME/jre/lib/ext) caused the second highest volume of
user problem reports (exceeded only by configuring web connectors).
These problems totally went away, once users understood how the new scheme
works (dump a JAR in the right place).

Second, neither CLASSPATH nor the system extensions directory gives you
enough control over the exposure of a particular JAR file to portions of
the container, or being able to mask it with a different version in a
controlled manner -- it's an all or nothing decision.

Third, most users are totally mystified by things like the following
scenario:
* Shared class loaded from system extension directory
* Application class loaded from WEB-INF
* Shared class tries to dynamically load application class (by name)
* ClassNotFoundException

Fourth, most users don't understand the security ramifications of putting
things in the system extensions directory -- these classes get all
permissions even if you are running under a security manager.

Fifth, putting things like servlet.jar in the system extensions directory
makes it totally impossible to support more than one version of the
servlet API on the same JVM -- you can have one and only one copy.

> 2) Can/Should there be a command line option to Tomcat:
> 	a) boolean to indicate use the CLASSPATH (default to false)
> 	b) define the classloader (like java.security.manager)
> 	c) add jar or ZIP files, or directories, to each part of the
> classloader (ie. add JDBC driver to common classloader)
>
> I am currently porting my application from WebLogic.  They dropped the whole
> CLASSPATH vs weblogic.class.path due to this class loader confusion.
>
> And I am quite aware of the "If you don't like it, change it" policy; just
> trying to feel some people out on the topic.  Perhaps this question is
> better served on the tomcat-dev mailing list, but I do still consider myself
> a "newbie".
>

It's been discussed on both the developer list and user list many times
before.  You're perfectly free to set up your own environment the way you
want -- you're also perfectly free to support it yourself.  As a
*volunteer* answering questions on this list (as well as a primary
developer of Tomcat 4), I'm not going to touch questions from people who
do this to themselves -- I've seen way too many people get totally burned
by classpath problems over the last five years.

> Thanks for listening.
>
> Mitchell Evan Marx        mmarx@att.com
> AT&T IP Network Configuration & Provisioning Development
>

Craig


--
To unsubscribe:   <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>