My guess is that it's because javaxml.jar includes servlet.jar inside
of it, and the j2ee rules say this is a nono ... I believe if you look
closely at the startup console log, you might see that your j2ee
container removes javaxml from your classpath because of that
violation? I have a vague recollection of this, at least. JavaXML is
pretty evil and really shouldn't exist. You don't actually need it --
it's just a pile of prebuilt jars ... Especially if you're using
maven, you should really unroll it and add the individual dependencies
instead.
ms
On Apr 17, 2009, at 12:40 AM, Jake MacMullin 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 protected]> 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 protected]>
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 protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/webobjects%40avendasora.com
This email sent to [email protected]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/jmacmullin%40gmail.com
This email sent to [email protected]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40mdimension.com
This email sent to [email protected]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
