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

Details

  • User impact:
    Medium
  • Similar Issues:
    None

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.

Issue Links

blocks

Task - A task that needs to be done. MULE-639 Investigate JDK 1.5 as base platform for upcoming Mule versions

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
is blocked by

Task - A task that needs to be done. MULE-2748 Document changes in XML prerequisites (break the OOTB build from the source)

  • Critical - Crashes, loss of data, severe memory leak.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
relates to

Bug - A problem which impairs or prevents the functions of the product. GALAXY-46 Newer XML libs must be endorsed on a JDK level

  • Critical - Crashes, loss of data, severe memory leak.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Task - A task that needs to be done. MULE-2858 Add Xalan 2.7.1 as endorsed dependency

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Andrew Perepelytsya added a comment -

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

  1. It'll cover only standalone mode naturally
  2. 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.

Show
Andrew Perepelytsya added a comment - A natural place for this validation could be the Mule's bootstrap process. However there are 2 concerns:
  1. It'll cover only standalone mode naturally
  2. 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.
Hide
Permalink
Holger Hoffstaette added a comment -

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

Show
Holger Hoffstaette added a comment - This will be done on a branch: https://svn.codehaus.org/mule/branches/mule-1.4-noxml/
Hide
Permalink
Holger Hoffstaette added a comment -

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..

Show
Holger Hoffstaette added a comment - 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..
Hide
Permalink
Holger Hoffstaette added a comment -

Outstanding tasks:

  • 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.
Show
Holger Hoffstaette added a comment - Outstanding tasks:
  • 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.
Hide
Permalink
Holger Hoffstaette added a comment -

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.

Show
Holger Hoffstaette added a comment - 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.
Hide
Permalink
Holger Hoffstaette added a comment -

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

Show
Holger Hoffstaette added a comment - As of r9911 the 2.x-jdk5 branch builds the full distribution + JCA etc. without any implicit XML dependencies, just like 1.x.
Hide
Permalink
Holger Hoffstaette added a comment -

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

Show
Holger Hoffstaette added a comment - r9971 contains the changes to the mule startup scripts to include the endorsed dir when starting on a 1.4 JVM.
Hide
Permalink
Holger Hoffstaette added a comment -

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.

Show
Holger Hoffstaette added a comment - 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.
Hide
Permalink
Holger Hoffstaette added a comment -

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.

Show
Holger Hoffstaette added a comment - 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.
Hide
Permalink
Dirk Olmes added a comment -

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.

Show
Dirk Olmes added a comment - 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.
Hide
Permalink
Holger Hoffstaette added a comment -

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

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

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: