Created attachment 92887 [details]
stacktrace

This bug already has 10 duplicates 
see http://statistics.netbeans.org/exceptions/detail.do?id=145711

So, what's happening here is this:

XMLInputFactory is in JDK 1.5 (ClassLoader 1)

The jaxws module depends on org.netbeans.libs.jaxb, which itself has a copy of XMLInputFactory (ClassLoader 2)

So it all goes to hell.

The possible solutions are:

a) Make the jaxb module use a parentfirst ClassLoader strategy (can this be done?) to get XMLInputFactory out of the JDK when available.

b) Make all modules which require XMLInputFactory depend (implementation dep) on the jaxb module (ugly, blech, and probably won't work since jaxb or jaxws uses Zephyr and another user is reporting an equivalent problem with Wstx, so there may be YetAnotherLoaderChain which breaks things)

c) Every module which requires STAX features to include yet another copy of the STAX API and force self-before-CCL loading semantics (ugly, blecch)

This bug is seriously affecting me at the moment, and I am trying to work out what to do about it.

I wrote a little routine which walks the superclass/loader chain of a class, and for each loader discovered, tries to load XMLInputFactory from that loader, and print where _that_ came from.

If we link against XMLInputFactory but do not depend on libs.jaxb, we get this:

print: Start of XMLInputFactory
print: Class = class javax.xml.stream.XMLInputFactory from null (system class loader)
print: Class = class java.lang.Object from null (system class loader)
print: End of XMLInputFactory


Now if we load ZephyrParserFactory using Class.forName, we get this:

print: Start of ZephyrParserFactory class
print: Class = class com.sun.xml.stream.ZephyrParserFactory from ModuleCL@16a23cf[org.netbeans.modules.websvc.jaxws21]
print: XMLInputFactory.class = class javax.xml.stream.XMLInputFactory from ModuleCL@5da37c[org.netbeans.libs.jaxb]
print: Class = class javax.xml.stream.XMLInputFactory from ModuleCL@5da37c[org.netbeans.libs.jaxb]
print: XMLInputFactory.class = class javax.xml.stream.XMLInputFactory from ModuleCL@5da37c[org.netbeans.libs.jaxb]
print: Class = class java.lang.Object from null (system class loader)
print: End of ZephyrParserFactory class

I have moved this to platform/module-system from UML because it has nothing whatsoever to do with UML. The solution lies either in the classloading order in the platform, or at worst a reconfiguration of the jaxb module to prefer the system class loader. I got lost in the shouldDelegateResource() maze, so I can't determine myself.

xml.jaxb.api is using OpenIDE-Module-Hide-Classpath-Packages on javax.xml.bind.**, which is probably OK, but I don't think it should be touching javax.xml.stream.* since the JRE already includes this as of Java 6 (and JDK 5 is no longer supported by NB). Try removing jsr173_api.jar from the build.

I can't find any reference to XMLInputFactory in libs.jaxb in dev sources; maybe things were refactored after 6.8.

Thank you, jesse. I had just gotten as far as digging into this myself:

http://bits.netbeans.org/dev/javadoc/org-openide-modules/apichanges.html#OpenIDE-Module-Hide-Classpath-Packages

and am now trying to work out why this broke in 6.7, which I and many of our users are running.

Ah, of course I was one step behind you. I now (think I) understand that the Hide statement says "Do not load this from the JDK for this class." whereas on JDK6, we WANT it loaded from the JDK, otherwise the world breaks for us and our module.

The other note is that the solution to this is to make a dep on the jaxb lib, which can only be done as an impl dep, even though it has no public API, therefore no reason to forbid a (nominal) API dep. But if you do that, you get this, even though XMLEventAllocator is in the jsr173 JAR AND the JDK.

SEVERE DefaultSwingWorker error: Error in Swing background task: java.lang.NoClassDefFoundError: javax/xml/stream/util/XMLEventAllocator
        at com.sun.xml.stream.ZephyrParserFactory.createXMLEventReader(ZephyrParserFactory.java:92)

Sigh.

I have moved to 6.8 where the XMLInputFactory is not masked. The trouble now is that the JAXB APIs still use the embedded JAR, so the problem still exists. Basically, calling XMLInputFactory.newInstance() when JAXB is in the ContextClassLoader but is not in the ClassLoader (i.e. from any module which wants to process XML using the JDK and doesn't take special account of NetBeans JAXB module) throws a ClassCastException.

Here is the debug output from my test routine in 6.8:

print: Start of WstxInputFactory class
print: Class = class com.ctc.wstx.stax.WstxInputFactory from ModuleCL@d8c3ee[org.netbeans.modules.websvc.jaxws21]
test: XMLInputFactory.class = class javax.xml.stream.XMLInputFactory from ModuleCL@1abcd9b[org.netbeans.modules.xml.jaxb.api]
test: Loader.shouldDelegateResource = false 
test: Module = StandardModule:org.netbeans.modules.websvc.jaxws21 jarFile: /home/shevek/netbeans-6.8/java3/modules/org-netbeans-modules-websvc-jaxws21.jar
test: ModuleManager.shouldDelegateResource = false 
print: Class = class org.codehaus.stax2.XMLInputFactory2 from ModuleCL@d8c3ee[org.netbeans.modules.websvc.jaxws21]
test: XMLInputFactory.class = class javax.xml.stream.XMLInputFactory from ModuleCL@1abcd9b[org.netbeans.modules.xml.jaxb.api]
test: Loader.shouldDelegateResource = false 
test: Module = StandardModule:org.netbeans.modules.websvc.jaxws21 jarFile: /home/shevek/netbeans-6.8/java3/modules/org-netbeans-modules-websvc-jaxws21.jar
test: ModuleManager.shouldDelegateResource = false 
print: Class = class javax.xml.stream.XMLInputFactory from ModuleCL@1abcd9b[org.netbeans.modules.xml.jaxb.api]
test: XMLInputFactory.class = class javax.xml.stream.XMLInputFactory from ModuleCL@1abcd9b[org.netbeans.modules.xml.jaxb.api]
test: Loader.shouldDelegateResource = false 
test: Module = StandardModule:org.netbeans.modules.xml.jaxb.api jarFile: /home/shevek/netbeans-6.8/ide12/modules/org-netbeans-modules-xml-jaxb-api.jar
test: ModuleManager.shouldDelegateResource = false 
print: Class = class java.lang.Object from null
print: End of WstxInputFactory class

In other words, WstxInputFactory, which is advertised on the public ClassPath as an XMLInputFactory, is not an XMLInputFactory, it's a (private-copy-of)XmlInputFactory, which is No Good At All.

WFM in 7.1dev. I verified (in debugger) that even JAXB* NB modules get their XMLInputFactory from the JDK rather than from the bundled jsr173.jar.

We should throw out jsr173 in the next release cycle ?

Removed jsr173 as well as Woodstox jars from the class path. Jsr173 API as well as its implementation is part of JDK (since 1.6).

See: http://hg.netbeans.org/web-main/rev/bbe2eea18996

Please, verify.

Integrated into 'main-silver', will be available in build *201308090746* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)

Changeset: http://hg.netbeans.org/main-silver/rev/bbe2eea18996
User: Milan Kuchtiak <mkuchtiak@netbeans.org>
Log: #179003 removed Woodstox as well as jsr173 libraries from netbeans classpath