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]>
