Yes, thank you again Nathan for your thorough and helpful analysis
of the AXIS/Tomcat installation and version match-up issues.
However, I have to take one small exception to your remark:
> With an out-of-the-box Tomcat 4.0.1 or Tomcat 4.0.4-b2, I can install a
> perfectly functioning out-of-the-box Axis according to the installation
> documentation provided.
In my experience, not quite. Step 5 of the xml-axis-beta1 install.html
fails to include jaxrpc.jar among the files that are instructed to be
placed on the system classpath (the others mentioned being axis.jar,
commons-logging.jar, log4j-core.jar, tt-bytecode.jar, and XML parser
jar files).
Without jaxrpc.jar on the classpath, I get a NoClassDefFoundError
for javax/xml/soap/SOAPElement when attempting command-line deployment
of a web service as described in that step, since jaxrpc.jar contains
that class.
At least it remains true, as you state, that with Tomcat 4.0.4-b2-01
there is no need for copying jar files from the webapps directories
to tomcat /lib directories. This is indeed a good thing.
Just wanted to note that one omission in the AXIS install instructions,
since it caused me a little hiccup.
Best regards,
-- Ivan
| "Nathan D. Bowen" <[EMAIL PROTECTED]>
04/09/2002 12:45 PM
|
To: [EMAIL PROTECTED] cc: Subject: Axis trouble with Tomcat 4.0.2 and 4.0.3 (was Re: XML Parsers and Classloading in Tomcat) |
On Tue, Apr 09, 2002 at 12:43:30PM -0400, Madan, Kapil wrote:
> I would also suggest the same Tomcat 4.0.x
> it works without trouble even for Axis or Soap2.2
> !!
>
> -----Original Message-----
> From: Ng, Charles [mailto:[EMAIL PROTECTED]]
> Sent: 09 April 2002 17:41
> To: '[EMAIL PROTECTED]'
> Subject: RE: XML Parsers and Classloading in Tomcat
>
>
> Just out of curiosity, why are you not using Tomcat 4.0.x? Tomcat 3.x is
> notorious for class loader problems because of the ambiguous class loader
> scoping specification (or lack thereof) in the Servlet 2.2 API.
Not so fast with the "Tomcat 4.0.x" recommendations.
I got myself in some trouble by assuming that "Tomcat 4.0.x" would work
without trouble. As a few people seem to have noticed, some versions of
Tomcat have a classloader bug that prevents Axis from working
out-of-the-box. The problem appeared in 4.0.2, and lasted through 4.0.3.
It wasn't present in 4.0.1, and it's fixed in 4.0.4-b2.
It infuriated me for the entirety of yesterday until I found it mentioned
in the archives of this list. (Thanks, by the way, to the person who posted
that tidbit; it saved my sanity yesterday.)
I was curious enough to investigate a bit further, and I've included the
details of what I believe to be the relevant Tomcat behavior below. Keep in
mind that I don't really know anything about the Tomcat source and I speak
with no authority on the matter at all.
My apologies if I'm missing something here and this has been working fine
for everyone other than me. I'm pretty sure that's not the case, but it's
always possible.
The summary, first, is that my recommendation would be:
Run Axis in Tomcat 4.0.1 or 4.0.4-beta
Never run Axis in Tomcat 4.0.3 or 4.0.2.
With 4.0.3 being the current "latest non-beta" version of Tomcat, the
recommendation to use "Tomcat 4.0.x" convinced me (and others, I'm
guessing) that 4.0.3 would work flawlessly.
It should be noted that Tomcat 4.0.3 and 4.0.2 can both be made to work
with a "copying jars into a tomcat lib/ directory" workaround. This is
alright, for testing and such, but if someone wants to run more than one
Tomcat instance out of the same CATALINA_HOME, it's not always fair to
assume they want all of those instances to share the same version of all of
their libraries (especially beta libraries).
With an out-of-the-box Tomcat 4.0.1 or Tomcat 4.0.4-b2, I can install a
perfectly functioning out-of-the-box Axis according to the installation
documentation provided.
That said, considering the frustration experienced by anyone following
those same instructions with Tomcat 4.0.2 and 4.0.3, I'd personally think
that the Axis install.html document might do well to state that Axis is
simply not compatible with those two versions.
It's commendable that install.html is written to be as independent of
deployment environment as it is, but I have to assume that a very large
number of Axis users are also Tomcat users.
I suppose that the install.html would've gotten me up and running just as
quickly if it mentioned the jar-copying workaround, but I'll admit that I'm
far too biased against that solution to advocate its being suggested to
anyone. Ever. That may just be me, though.
>From what I see in the CVS logs for WebappClassLoader, the problems in
question have evolved somewhat like this:
Tomcat 4.0.1's WebappClassLoader wouldn't load a class whose fully
qualified name began with "java.", or whose exact package name was any of
the following:
javax.servlet
javax.servlet.http
javax.servlet.jsp
javax.servlet.jsp.tagext
Tomcat 4.0.2 and 4.0.3 shared a WebappClassLoader which wouldn't load a
class whose fully qualified name began with any of the following:
java.
javax.net.
javax.security.cert.
javax.naming.
javax.xml.
org.xml.sax.
org.w3c.dom.
and additionally wouldn't load a jar that contained any of the following
classes:
com.sun.jndi.ldap.LdapCtxFactory
com.sun.net.ssl.internal.ssl.Provider
javax.security.auth.Subject
javax.servlet.Servlet
In the case of the error I was experiencing, this problem made it
impossible to load the classes in jaxrpc.jar from the webapp's classpath,
and therefore a successful workaround was to copy jaxrpc.jar into one of
Tomcat's other classpaths. This solution might be sufficient for some, but
I anticipate having a future requirement for two different tomcat instances
running from the same CATALINA_HOME, each with a different version of the
Axis libraries.
Luckily, Tomcat 4.0.4-b1 and Tomcat 4.0.4-b2 have changed the
WebappClassLoader. Starting with Tomcat 4.0.4-b1, the WebappClassLoader
will refuse to load a class whose fully qualified name begins with any of:
java.
javax.naming
javax.naming.directory
javax.xml.parsers
org.xml.sax
org.xml.sax.ext
org.xml.sax.helpers
org.w3c.dom
and additionally will not load a jar that contains the class:
javax.servlet.Servlet
Since the javax.xml package is no longer forbidden (only javax.xml.parsers,
specifically, is forbidden), the jaxrpc.jar's javax.xml.messaging,
javax.xml.rpc, javax.xml.soap, and javax.xml.transform classes are once
again loadable by the WebappClassLoader.
Here's hoping it stays that way.
--
Nathan D. Bowen
[EMAIL PROTECTED]
