Re: JavaXML.framework Question
Re: JavaXML.framework Question
- Subject: Re: JavaXML.framework Question
- From: Jake MacMullin <email@hidden>
- Date: Wed, 22 Apr 2009 09:39:15 +1000
Yes, I can confirm this problem was due to the fact that JavaXML.jar contains the Servlet classes (usually found in servlet.jar). I found the following in a log file:
The relevent section of the Servlet Spec 2.3 says:
"The classloader that a container uses to load a servlet in a WAR must allow the
developer to load any resources contained in library JARs within the WAR
following normal J2SE semantics using getResource. It must not allow the WAR to
override J2SE or Java servlet API classes" (my emphasis)
It appears that the JavaXML-5.4.2.jar includes a copy of the javax/servlet/Servlet.class which is part of the 'Java servlet API' and this Tomcat is (correctly) not allowing the .jar to be loaded as the Servlet Spec says containers should not allow WARs to override classes in the servlet API. This class is needed at build time - but is provided by servlet containers at run time, so it should not be present in deployed applications. Perhaps Tomcat is being over-zealous in refusing to load the entire JavaXML jar due to a few classes that it should ignore (and perhaps Jetty just ignores the specific classes (or ignores the Spec)), but in order to deploy WARs in 'compliant' containers, it would seem this class should be excluded.
Apple, is it possible to have a release of WO where the servlet API is not embedded within the JavaXML jar? That way we could refer to it and build time (if needed), but it would not be deployed as part of the WAR?
Thanks,
Jake
PS - Mike, I might try your suggestion of just referencing the required libraries directly. Problem is I'm not sure exactly what we need. As far as I know we're not using anything in JavaXML directly - but using some part of WO that itself has a dependency on something in JavaXML... I guess I need to look in to this more.
On Fri, Apr 17, 2009 at 2:40 PM, Jake MacMullin
<email@hidden> wrote:
I've encountered this same problem (sans-wonder) when deploying WebObjects applications built as WARs to Tomcat, JBoss (with a Tomcat servlet container) and Glassfish application servers - though not with Jetty.
I'd really like to know more about what might be causing this problem and what the solution is. I suspect that it might be due to incompatibilities between versions of java libraries included within the javaxml.jar and different versions of the same libraries provided by the various application servers. I'm currently seeing if I can figure out exactly what is causing this problem as it is a serious issue if we're unable to deploy to JBoss/Tomcat as that's our current server set-up.
I first noticed this problem with WO 5.4.x (sans-wonder).
Regards,
Jake
On Wed, Apr 15, 2009 at 2:18 AM, Dov Rosenberg
<email@hidden> wrote:
Yes, we have swapped over to Wonder a few months ago. I have run into this prior to Wonder though.
Dov
On 4/14/09 12:01 PM, "David Avendasora" <
email@hidden> wrote:
Hi Dov,
Are you using Wonder with your Tomcat servlet apps? I've run into some classpath weirdness with running the two together. The weirdness I see is different from what you are running into, but maybe they are related...
Dave
On Apr 14, 2009, at 11:39 AM, Dov Rosenberg wrote:
We deploy our apps as servlets in Tomcat. We have been deploying them that way for the past few years. Recently I have been updating our build scripts to steamline them. For some reason even though we include the javaxml.jar (from the JavaXML.framework) in our WEB-INF/lib folder the Tomcat class loader can’t seem to find classes that I can see in the jar. For example at startup if I don’t include xercesImpl.jar in my WEB-INF/lib along side javaxml.jar I will see the following error
java.lang.NoClassDefFoundError: org/apache/xml/serialize/OutputFormat: org/apache/xml/serialize/OutputFormat
That class is in both the xercesImpl and javaxml.jar’s
The same seems to apply for the xalan, axis, wsdl, etc classes. Should we be deploying the JavaXML.framework at all? It seems that if we do not the webservices functionality built into WebObjects gets broken. Seems like a waste to deploy all of these duplicate wars.
Thanks in advance for any feedback
Dov Rosenberg
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (
email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden