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

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.

Jacob Kjome
added a comment - 20/Feb/10 04:41 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

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.

Dannes Wessels
added a comment - 20/Feb/10 16:06 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

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.

Michael Glavassevich
added a comment - 07/Mar/10 09:44 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.

Dannes Wessels
added a comment - 19/Jun/10 21:58 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?