XML Commons
  1. XML Commons
  2. XMLCOMMONS-80

javax.xml.stream.XMLOutputFactory should not depend on woodstox/WstxOutputFactory

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Won't Fix
    • Affects Version/s: 1.x
    • Fix Version/s: None
    • Labels:
      None
    • Environment:
      Operating System: other
      Platform: Macintosh

      Description

      I did put xml-apis.jar (version 1.4) in my application endorsed directory, to be sure that everyone runs/builds against the right XML-apis.

      Unfortunately this introduces a dependency with the codehause / woodstox implementation, in my case com.ctc.wstx.stax.WstxOutputFactory ; see line 30:

      http://svn.apache.org/viewvc/xml/commons/trunk/java/external/src/javax/xml/stream/XMLOutputFactory.java?view=markup

      In my project this dependency is 'undesired'. The bad thing here is that I cannot override this default implementation. Since the application runs e.g. in tomcat, setting a system property is difficult / impossible.

      The second issue is that it is not possible to explicitly reference to the com.sun... implementation from my code, since one can not rely on running in the Sun JVM.

      So my question:

      • why the woodstox dependency?
      • please could you remove this dependency?

      It might be a good idea add some notes regarding this on the xml-commons web pages.

      Should xml-apis.jar be in the jvm/application endorsed directory?

        Activity

        Hide
        Dannes Wessels added a comment -

        Great to see 2.10 being released. super!

        ABout this issue: why not fallback to the default sun implementation if this implementation is available? For an enduser this is IMO much more transparent.

        STAX is part of the language since Java6, why not use the default implementation? All implementations are required to provide it?

        Show
        Dannes Wessels added a comment - Great to see 2.10 being released. super! ABout this issue: why not fallback to the default sun implementation if this implementation is available? For an enduser this is IMO much more transparent. STAX is part of the language since Java6, why not use the default implementation? All implementations are required to provide it?
        Hide
        Michael Glavassevich added a comment -

        This is no different than any of the other JAXP factories, each of which nominate a default implementation when none could be found through its search mechanism. If you merely place xml-apis.jar in the endorsed directory of a Sun JDK you'll also get errors about not being able to find Xerces or Xalan.

        The Apache distribution has its own set of defaults which may be different from some other platform's. They were chosen intentionally, in this case to point to the ASL licensed StAX implementation used by Apache projects which I could argue is a far more appropriate value than Sun's proprietary implementation (which only exists in their JDK).

        If you put xml-apis.jar in the endorsed directory you also need a JAXP / StAX implementation on your classpath. These will be picked up through the META-INF/services files in their jars.

        There is no bug here.

        Show
        Michael Glavassevich added a comment - This is no different than any of the other JAXP factories, each of which nominate a default implementation when none could be found through its search mechanism. If you merely place xml-apis.jar in the endorsed directory of a Sun JDK you'll also get errors about not being able to find Xerces or Xalan. The Apache distribution has its own set of defaults which may be different from some other platform's. They were chosen intentionally, in this case to point to the ASL licensed StAX implementation used by Apache projects which I could argue is a far more appropriate value than Sun's proprietary implementation (which only exists in their JDK). If you put xml-apis.jar in the endorsed directory you also need a JAXP / StAX implementation on your classpath. These will be picked up through the META-INF/services files in their jars. There is no bug here.
        Hide
        Dannes Wessels added a comment -

        Note: issue confirmed on Sun JVM on windows (32 bits) and the derived version on MacOsX (64 bit). Both Java6u17 or u18

        Show
        Dannes Wessels added a comment - Note: issue confirmed on Sun JVM on windows (32 bits) and the derived version on MacOsX (64 bit). Both Java6u17 or u18
        Hide
        Dannes Wessels added a comment -

        Since Java6 a default implementation is part of the JVM, e.g. check http://kickjava.com/src/javax/xml/stream/XMLOutputFactory.java.htm : for the sun jvm the default implementation is com.sun.xml.internal.stream.XMLOutputFactoryImpl , for other vendors (classpath?harmony?) this will be a different class.

        You are right that via the 'service registry' the sun implementation should be found, but this is onfortunately not the case. The factoryFinder scans all jar files on the classpath, and reads for the "META-INF/services/"thing in there. SUn does not set this service thing for its own jar files.

        IMO it would be logical to choose for com.sun.xml.internal.stream.XMLOutputFactoryImpl by default. Best alternative is probably to use some reflection on the presence of some alternative implementations as well.

        Note that just by putting xml-api.jar on the classpath my application stopped working. For our project there is no need to have an other StAX implementation than a simple default one provided by the JVM.

        I think closing this report is not a good thing. please reconsider

        regards

        Dannes

        Show
        Dannes Wessels added a comment - Since Java6 a default implementation is part of the JVM, e.g. check http://kickjava.com/src/javax/xml/stream/XMLOutputFactory.java.htm : for the sun jvm the default implementation is com.sun.xml.internal.stream.XMLOutputFactoryImpl , for other vendors (classpath?harmony?) this will be a different class. You are right that via the 'service registry' the sun implementation should be found, but this is onfortunately not the case. The factoryFinder scans all jar files on the classpath, and reads for the "META-INF/services/"thing in there. SUn does not set this service thing for its own jar files. IMO it would be logical to choose for com.sun.xml.internal.stream.XMLOutputFactoryImpl by default. Best alternative is probably to use some reflection on the presence of some alternative implementations as well. Note that just by putting xml-api.jar on the classpath my application stopped working. For our project there is no need to have an other StAX implementation than a simple default one provided by the JVM. I think closing this report is not a good thing. please reconsider regards Dannes
        Hide
        Jacob Kjome added a comment -

        There is no hard dependency on Woodstox here. What you need to do is place a jar file containing your preferred Stax implementation in the classpath. That jar will provide its own implementations and be registered via the service registry. The default value in xml-apis.jar is a fallback. No need to set a system property or anything like that. I think the value was chosen probably because it was the first (or preferred) implementation chosen by the developer of the Stax API. It is not relevant if you provide your own implementation which is something you really have to do anyway.

        I would suggest resolving this bug as there is no issue here that I can see.

        Jake

        Show
        Jacob Kjome added a comment - There is no hard dependency on Woodstox here. What you need to do is place a jar file containing your preferred Stax implementation in the classpath. That jar will provide its own implementations and be registered via the service registry. The default value in xml-apis.jar is a fallback. No need to set a system property or anything like that. I think the value was chosen probably because it was the first (or preferred) implementation chosen by the developer of the Stax API. It is not relevant if you provide your own implementation which is something you really have to do anyway. I would suggest resolving this bug as there is no issue here that I can see. Jake

          People

          • Assignee:
            Unassigned
            Reporter:
            Dannes Wessels
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development