Nathan, Thanks for putting this out. I was also going nuts trying to get Axis up on various versions of Tomcat. Works now on 4.0.4-b2-01, right out of the box.
Walden Mathews > -----Original Message----- > From: Nathan D. Bowen [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, April 09, 2002 3:45 PM > To: [EMAIL PROTECTED] > 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] >
