5 Replies Latest reply on Feb 8, 2010 9:34 AM by Richard Opalka

    Removing xalan.jar

    Dimitris Andreadis Master

      (I'm copying the discussion from the dev-list here for reference)

      "dimitris@jboss.org" wrote:

      I tried to remove lib/endorsed/xalan.jar in 4.0.x and the situation is as follows:

      Works fine under jdk1.5, but breaks under jdk5 when the XSLSubDeployer does a

      TransformerFactory tf = TransformerFactory.newInstance();

      The problem is lib/endorsed/xml-apis.jar includes a javax.xml.transform.TransformerFactory that simply points to org.apache.xalan.processor.TransformerFactoryImpl, if the javax.xml.transform.TransformerFactory property is not set!

      And that overrides the jdk5 javax.xml.transform.TransformerFactory that points to com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.

      If (when run under jdk5) I set
      -Djavax.xml.transform.TransformerFactory=com.sun.org.apache.xalan.intern
      al.xsltc.trax.TransformerFactoryImpl, but I don't know if this should work with all jdk5 jdks.

      What options do we have? Hack xml-apis to remove the offending javax.xml.transform.TransformerFactory class?

      "scott.stark@jboss.org" wrote:

      The question is where the the xml-apis.jar come from then? It should not include a TransformerFactory if its not from the xalan distribution which is what I suspect. The origin of the xml jars needs to be validated and if the xerces distribution defaults to configuring a TransformerFactory, that should be removed.

      The xml parser is needed to override the buggy jdk version.

      "dimitris@jboss.org" wrote:

      I traced this down to a TranformerFactory included in the xml-apis.jar that comes with xerces tools (e.g. Xerces-J-tools.2.7.1.zip).

      This is tagged as 1.3.02 and in turn originates from http://xml.apache.org/commons/

      The xml-commons hadn't had any releases for some time, so the tagged xml-apis.jar comes directly from their cvs.

      I think I will remove all javax.xml.transform.** from xml-apis.jar to create a new xml-apis-no-transform.jar and include this instead.

      From a quick test it seems to be working with both jdk1.4 and jdk5.

      "scott.stark@jboss.org" wrote:

      This is probably a jaxp requirement to not subset the apis. The next question is whether the xml-apis.jar is needed. Is jdk1.4.x at jaxp 1.2?
      The xerces 2.7.x release supports jaxp 1.3.

      The potential problem with doing this is are there dependencies between the javax.xml.transform.* classes and the other javax.xml.* classes.

      The more I think about it the more I doubt this is legal for a java ee distribution. If we are bundling jaxp 1.3, we need it to be the complete
      1.3 set of apis and we would just have to patch the TranformerFactory to do the right thing, whatever that is.

      "dimitris@jboss.org" wrote:

      It all boils down to here:
      ...
      return (TransformerFactory) FactoryFinder.find(
      /* The default property name according to the JAXP spec */
      "javax.xml.transform.TransformerFactory",
      /* The fallback implementation class name */
      "org.apache.xalan.processor.TransformerFactoryImpl");
      ...

      I don't see how we can patch the TF to return a proper fallback implementation name, because we just don't know what that is.

      On Sun jdk1.4 it would be
      org.apache.xalan.processor.TransformerFactoryImpl
      On Sun jdk5 it would be
      com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl
      But on other vendor jdks, whats the correct value?

      And if it is just a question of setting a sensible default value, we could do just the same setting the javax.xml.transform.TransformerFactory property.

      But isn't this exactly the role of the TransformerFactory offered by the jdk vendor?

      I think the best compromise is to just remove javax.xml.transform.TransformerFactory from xml-apis.jar (replace with xml-apis-notf.jar ?) to let the vendor supplied default apply.

      "scott.stark@jboss.org" wrote:

      Setting this via a system property cannot be done as this is a global override. We could simply externalize the default factory name to an attribute of the jboss server info mbean and fallback to the jdk default if it cannot be found. I don't know if an extension class can get access to a class from the jdk rt.jar via the ClassLoader.getSystemClassLoader().

      "dimitris@jboss.org" wrote:

      I don't follow why this is necessary. If we just remove javax.xml.transform.TransformerFactory from xml-apis.jar then the jdk bundled TransformerFactory will be used to choose the correct implementation.

      A user can always drop his own xalan.jar to lib/endorsed (for jdk1.4/5), or server/xxx/lib for jdk5, or use a scoped xalan.jar to override the jdk version, since xalan.jar contains:

      META-INF/services/javax.xml.transform.TransformerFactory file containing the class name of its implementation.

      "scott.stark@jboss.org" wrote:

      Its not clear that removal of the javax.xml.transform.* is safe. There are references to org.w3c.dom.* from the javax.xml.transform.dom for example. We cannot simply remove just the javax.xml.transform.TransformerFactory. It would have to be all
      javax.xml.transform.* classes.

      The presence of the javax.xml.transform.TransformerFactory should not affect a user being able to override the transformer by dropping in an xsl jar with a META-INF/services/javax.xml.transform.TransformerFactory
      entry as this takes precedence over the TransformerFactory defaults.

      "dimitris@jboss.org" wrote:

      Removing javax.xml.transform.TransformerFactory or patching it to try invoke the underlying TransformerFactory (if this is possible) which is essentially the same thing, is undesirable because you'll end up with a transformer API and an underlying implementation that may not match
      (correct?)

      Removing javax.xml.transform.* is not clear that is safe (I guess because you might have incompatible parser api+impl <-> transformer
      api+impl interactions?)

      Ok, we are doomed :)

      "scott.stark@jboss.org" wrote:

      > Removing javax.xml.transform.TransformerFactory or patching it to try
      > invoke the underlying TransformerFactory (if this is possible) which
      > is essentially the same thing, is undesirable because you'll end up
      > with a transformer API and an underlying implementation that may not
      > match
      > (correct?)
      >
      This is always the case though. Any attempt to override the xsl factory will be subject to matching the javax.xml.transform.* in effect.

      > Removing javax.xml.transform.* is not clear that is safe (I guess
      > because you might have incompatible parser api+impl <-> transformer
      > api+impl interactions?)
      >
      > Ok, we are doomed :)
      There are some xml parser class dependencies in the
      javax.xml.transform.dom and javax.xml.transform.sax packages. I just
      don't know if the javax.xml.transform.* in jaxp 1.3 can use the 1.2 xml
      parsers.

      It's a tradeoff between introducing a xsl parser dependency that the
      user may not want vs modifying the TransformerFactory to be more
      flexible at the cost of the user potentially have to configure the
      TransformerFactory default. I think modifying the TransformerFactory is
      the most flexible, but maybe just bundling the xsl parser is the
      simplest.


        • 1. Re: Removing xalan.jar
          Richard Opalka Master

          I don't wanna sound PITA and I know this is the never ending story discussion
          but why we're still not removing it?


          I think it's time to remove xalan from JBoss or at least from endorsed directory.

          I came to this when I started analyzing
          https://jira.jboss.org/jira/browse/JBWS-2917

          So my question is does some project depend on packages:

            * org.apache.xalan.*
            * org.apache.xml.*
            * org.apache.xpath.*

          from xalan.jar or it's problem of JVM incorporating buggy implementation of it?
          I see from https://jira.jboss.org/jira/browse/JBAS-2073
          that in the past there used to be a buggy implementation in JDK 4.

          According to http://community.jboss.org/message/346954#346954
          there used to be some issues in the past when endosing xalan.jar
          together with xml-apis.jar on JDK5.
          But now xml-apis.jar isn't endorsed any more and we're just supporting JDK6 and above.

          I also see we're using some brew version of it (incorporating some xalan patches).
          The issues these patches are trying to solve are also in implementation of supported JVMs?

          I found that JBossWS depends on xalan https://jira.jboss.org/jira/browse/JBWS-2919 (should be fixed soon).

          How about other projects? Do MC, JBossXB or some other projects depend on xalan directly?

          • 2. Re: Removing xalan.jar
            Brian Stansberry Master
            I suggest you ask this question on the jboss-development mailing list. Relevant people may not follow this forum. I saw this post quite by accident.
            • 3. Re: Removing xalan.jar
              jaikiran pai Master

              And since this question is more related to JBoss AS development than "Miscellaneous Development", i'll move it to our AS dev forum.

              • 4. Re: Removing xalan.jar
                Ales Justin Master

                How about other projects? Do MC, JBossXB or some other projects depend on xalan directly?

                For anything XML related, MC depends on XB.


                • 5. Re: Removing xalan.jar
                  Richard Opalka Master
                  I executed tattletale against AS trunk and it reports
                  the following jars are dependent on xalan impl. classes:

                  JBoss code:
                  * jbossws-native-core.jar (JBoss Web Services)
                  * jbossxacml.jar (JBoss Security)

                  Thirdparty code (from apache.org)
                  * bsf.jar
                  * xmlsec.jar

                  I fixed jbossws-native-core.jar to don't use xalan classes directly (JBWS-2919)
                  I reported issue to security project to don't depend directly on xalan classes too (SECURITY-452)

                  Unfortunately thirdparty bsf.jar and xmlsec.jar (from apache.org) depend on xalan directly too.

                  Dimitris, I see you're the author of
                  https://svn.jboss.org/repos/jbossas/trunk/varia/src/main/java/org/jboss/monitor/services/ScriptingListener.java
                  that brings in support for dynamic languages.

                  From BSF configuration file I can see:
                  ---
                  # List of script types and their associated scripting engines
                  #
                  # languageDescriptor = engineClass, ext1|ext2|... {, codebaseURL, ...}
                  #
                  # where exti are extensions for the language. Note that we leave
                  # all the engines enabled now and allow them to fail at load time.
                  # This way engines can be added by just adding to the classpath
                  # without having to edit this file. Cheating, really, but it works.
                  #
                  xslt = org.apache.bsf.engines.xslt.XSLTEngine, xslt
                  ---

                  The XSLTEngine from BSF uses xalan org.apache.xpath.objects.XObject class directly
                  This is not instatiated until xslt script is provided to ScriptingListener.

                  Q: Do we want to support xslt scripts as well via our scripting language support?
                  I guess yes?

                  Regarding xmlsec.jar from tattletale report I can see there are just two projects using it:

                  * JBoss Web Services
                  * JBoss Security

                  and this xmlsec.jar depends on the following xalan impl. classes:

                  org.apache.xml.dtm.DTM
                  org.apache.xml.dtm.DTMManager
                  org.apache.xml.utils.PrefixResolver
                  org.apache.xml.utils.PrefixResolverDefault
                  org.apache.xml.utils.URI
                  org.apache.xml.utils.URI$MalformedURIException
                  org.apache.xpath.CachedXPathAPI
                  org.apache.xpath.NodeSetDTM
                  org.apache.xpath.XPath
                  org.apache.xpath.XPathContext
                  org.apache.xpath.compiler.FunctionTable
                  org.apache.xpath.functions.Function
                  org.apache.xpath.objects.XNodeSet
                  org.apache.xpath.objects.XObject

                  This is the problem I don't know how to fix
                  But I see there's no reason to have xalan in endorsed directory
                  to make it work. We can move it away from
                  * $JBOSS_HOME/lib/endorsed
                  and copy it to
                  * $JBOSS_HOME/client
                  * $JBOSS_HOME/common/lib

                  What do you think guys?