[#MULE-2700] Mule must not add xml-apis/xerces to the classpath

Mule

Mule must not add xml-apis/xerces to the classpath

Created: 16/Nov/07 10:41 AM Updated: 24/Jan/08 05:49 PM

Component/s:

Build: Distributions, Build: JDK Compatibility, Build: Libraries / Dependencies, Modules: XML, XSLT, XPath

Affects Version/s:

1.4.3, 2.0.0-M2

Fix Version/s:

1.4.4

Time Tracking:

Not Specified

Issue Links:

Block

This issue blocks:

~~MULE-639~~ Investigate JDK 1.5 as base platform for upcoming Mule versions

This issue is blocked by:

~~MULE-2748~~ Document changes in XML prerequisites (break the OOTB build from the source)

Related

This issue relates to:

~~GALAXY-46~~ Newer XML libs must be endorsed on a JDK level

~~MULE-2858~~ Add Xalan 2.7.1 as endorsed dependency

Labels:	xml
User impact:	Medium

Description

« Hide

Since the m1->m2 migration and the cleanups of the XML dependencies both mule-core and module-xml reference xml-apis and xercesImpl, to provide working SAX/DOM capabilities when running on JDK 1.4. Since the PSR work and also future modules (CXF?) will require JDK 1.5/1.6 at both compile and run-time, these dependencies must be removed even though they seem to work correctly at the moment.
Handling the parser problem for JDK 1.4 through the "endorsed" mechanism is the only correct way, as the following two notes explain:
http://xerces.apache.org/xerces2-j/faq-general.html#faq-4
http://xml.apache.org/xalan-j/faq.html#faq-N100D6

The only correct scenarios are:

JDK 1.4: adding an XML implementation (xml-apis + xercesImpl or Sun's JAXP) to an endorsed directory, manually in <jre>/lib/endorsed and by adding a new directory for the service wrapper when starting Mule as server

JDK 1.5: by default no action necessary, though users MAY install an updated JAXP (see http://jaxp.dev.java.net/) in <jre>/lib/endorsed to update SAX/DOM or gain the new StAX capabilities introduced in JAXP 1.4 and shipping with JDK 1.6

JDK 1.6: no action necessary, and even though users MAY install an updated JAXP (see above) it is most likely not necessary as JAXP 1.4 revisions usually trail JDK 1.6 releases.

In any case, the bottom line is that regardless of JDK used for building or deploying, there must not be any xml-apis or xerces on the classpath, no matter what version. This makes checking for classpath violations very easy.

Description

Since the m1->m2 migration and the cleanups of the XML dependencies both mule-core and module-xml reference xml-apis and xercesImpl, to provide working SAX/DOM capabilities when running on JDK 1.4. Since the PSR work and also future modules (CXF?) will require JDK 1.5/1.6 at both compile and run-time, these dependencies must be removed even though they seem to work correctly at the moment. Handling the parser problem for JDK 1.4 through the "endorsed" mechanism is the only correct way, as the following two notes explain: http://xerces.apache.org/xerces2-j/faq-general.html#faq-4 http://xml.apache.org/xalan-j/faq.html#faq-N100D6 The only correct scenarios are:

JDK 1.4: adding an XML implementation (xml-apis + xercesImpl or Sun's JAXP) to an endorsed directory, manually in <jre>/lib/endorsed and by adding a new directory for the service wrapper when starting Mule as server

JDK 1.5: by default no action necessary, though users MAY install an updated JAXP (see http://jaxp.dev.java.net/) in <jre>/lib/endorsed to update SAX/DOM or gain the new StAX capabilities introduced in JAXP 1.4 and shipping with JDK 1.6

JDK 1.6: no action necessary, and even though users MAY install an updated JAXP (see above) it is most likely not necessary as JAXP 1.4 revisions usually trail JDK 1.6 releases.

An interesting corner case is our dependency on woodstox, which is not necessary when running on JDK 1.6 (as StAX is built in there); the good news is that there are no conflicts since the package names are completely different and therefore the discovery process does not get confused as with SAX/DOM. So woodstox can remain on the classpath for all JDKs, both when necessary (JDK 1.4/1.5 without endorsed JAXP 1.4) and redundant but harmless (JDK 1.6). In any case, the bottom line is that regardless of JDK used for building or deploying, there must not be any xml-apis or xerces on the classpath, no matter what version. This makes checking for classpath violations very easy.

Show »

All

Comments

Work Log

Change History

Transitions

FishEye

Sort Order:

[ Permlink | « Hide ]

Andrew Perepelytsya added a comment - 16/Nov/07 10:47 AM

A natural place for this validation could be the Mule's bootstrap process. However there are 2 concerns:

It'll cover only standalone mode naturally
There are some pending merges for this module, extra modifications will add more work later (though it doesn't mean we shouldn't do it).

E.g. if a well-known jar name pattern is found, Mule can fail early with suggestions on how to do the XML libs endorsement properly.

[ Permlink | « Hide ]

Holger Hoffstaette added a comment - 16/Nov/07 10:50 AM

This will be done on a branch:
https://svn.codehaus.org/mule/branches/mule-1.4-noxml/

[ Permlink | « Hide ]

Holger Hoffstaette added a comment - 16/Nov/07 10:55 AM

Andrew, yes I've also been thinking about some kind of validation though it's really only necessary for JDK 1.4. One possible and cheap check would be to just get a SAXParserFactory and only complain if it's the blacklisted JDK 1.4 Crimson implementation.
Btw this is only the tip of the iceberg: we've had much worse compatibility problems coming out of the Japex work because of JAXB and JDK5/6 which required JDK-specific dependency management too - as JDK 1.6 has JAXB built in but not the version we use for JDK 1.5 and then complains about binary incompatibility with jaxb-api and aargh..

[ Permlink | « Hide ]

Holger Hoffstaette added a comment - 20/Nov/07 08:45 AM

1.4 is now XML-free:
http://fisheye.codehaus.org/changelog/mule/?cs=9785
http://fisheye.codehaus.org/changelog/mule/?cs=9789
http://fisheye.codehaus.org/changelog/mule/?cs=9791

[ Permlink | « Hide ]

Holger Hoffstaette added a comment - 20/Nov/07 10:01 AM

Outstanding tasks:

document instructions (http://www.nabble.com/Heads-up%3A-mule-1.4%2C-XML%2C-and-you-tf4838003.html) on http://mule.mulesource.org/display/MULE/Building+from+Source

merge into 2.x, depending on the 2.x team's timeline

plan on possible service wrapper extension, if deemed necessary. I understand that in some multi-user environments modifications to the installed jdk/jre are not possible.

[ Permlink | « Hide ]

Holger Hoffstaette added a comment - 22/Nov/07 12:05 PM

Progress note: as of http://fisheye.codehaus.org/changelog/mule/?cs=9822 the necessary XML jars are included in the full distribution in a separate "lib/endorsed" directory. Still need to figure out a good way to add this to the service wrapper when necessary; currently I tend towards making the user explicitly enable this when JDK 1.4 is used.

[ Permlink | « Hide ]

Holger Hoffstaette added a comment - 28/Nov/07 08:26 AM

As of r9911 the 2.x-jdk5 branch builds the full distribution + JCA etc. without any implicit XML dependencies, just like 1.x.

[ Permlink | « Hide ]

Holger Hoffstaette added a comment - 04/Dec/07 07:45 AM

r9971 contains the changes to the mule startup scripts to include the endorsed dir when starting on a 1.4 JVM.

[ Permlink | « Hide ]

Holger Hoffstaette added a comment - 04/Dec/07 11:01 AM

r9982 contains a check for MuleManager that verifies a valid JAXP installation; MM will complain loudly & exit if it is started e.g. with stock JDK 1.4.2.

[ Permlink | « Hide ]

Holger Hoffstaette added a comment - 05/Dec/07 11:07 AM

All necessary changes are implemented, verified and documented. The XML removal in 2.x still needs to be merged from the 2.x-jdk5 branch whenever the 2.x team wants to, therefore I removed 2.x from the fix-version.

[ Permlink | « Hide ]

Dirk Olmes added a comment - 17/Jan/08 05:17 AM

Now that we can effectively build Mule using JDK 1.5 it turns out that the JDK 1.5 scenario from this issue's description is not 100% correct. In order to build Mule using JDK 1.5 you must have an endorsed dir with the specified jars in order to successfully run all unit tests.

[ Permlink | « Hide ]

Holger Hoffstaette added a comment - 17/Jan/08 05:25 AM

The primary issue was about compiling, not running :-D
But yes, endorsed stuff is necessary for 1.5 as well. Blame Sun..