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 [EMAIL PROTECTED]
AT&T IP Network Configuration & Provisioning Development
-----Original Message-----
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
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 <[EMAIL PROTECTED]>
> Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Tomcat 4.01 classloader problem? (Craig)
>
> Santosh on [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
> Boulder CO 80303-2616
--
To unsubscribe: <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe: <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>
