8 Replies Latest reply on Oct 24, 2011 6:18 PM by avernet

How to debug an incorrect module dependency in JBoss 7?

avernet Oct 20, 2011 1:50 AM

I have a web app, which uses Sun's MSV library. All the classes for MSV are included in jars in the web app WEB-INF/lib. When deploying this app on JBoss 7, I get the following exception:

java.lang.NoClassDefFoundError: Could not initialize class com.sun.msv.datatype.xsd.AnyURIType

at com.sun.msv.datatype.xsd.DatatypeFactory.getTypeByName(DatatypeFactory.java:195)

at com.sun.msv.datatype.xsd.ngimpl.DataTypeLibraryImpl.getType(DataTypeLibraryImpl.java:32)

at com.sun.msv.datatype.xsd.ngimpl.DataTypeLibraryImpl.createDatatypeBuilder(DataTypeLibraryImpl.java:36)

at com.sun.msv.reader.trex.ng.DataState.startSelf(DataState.java:58)

at com.sun.msv.reader.State.init(State.java:153)

at com.sun.msv.reader.GrammarReader.pushState(GrammarReader.java:576)

at com.sun.msv.reader.SimpleState.startElement(SimpleState.java:71)

at org.xml.sax.helpers.XMLFilterImpl.startElement(XMLFilterImpl.java:527)

at com.sun.msv.reader.trex.TREXBaseReader.startElement(TREXBaseReader.java:184)

at com.sun.msv.reader.trex.ng.RELAXNGReader.startElement(RELAXNGReader.java:524)

at com.sun.msv.reader.trex.ng.comp.RELAXNGCompReader.startElement(RELAXNGCompReader.java:197)

at orbeon.apache.xerces.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:497)

at orbeon.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(AbstractXMLDocumentParser.java:180)

at orbeon.apache.xerces.xinclude.XIncludeHandler.emptyElement(XIncludeHandler.java:1024)

at orbeon.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:275)

at orbeon.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1654)

at orbeon.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:324)

at orbeon.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:845)

at orbeon.apache.xerces.parsers.XML11Configuration.parse(XML11Configuration.java:768)

at orbeon.apache.xerces.parsers.XMLParser.parse(XMLParser.java:108)

at orbeon.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1201)

at com.sun.msv.reader.util.GrammarLoader._loadSchema(GrammarLoader.java:514)

at com.sun.msv.reader.util.GrammarLoader.parse(GrammarLoader.java:325)

at com.sun.msv.reader.util.GrammarLoader.loadSchema(GrammarLoader.java:189)

at com.sun.msv.verifier.jarv.TheFactoryImpl.parse(TheFactoryImpl.java:42)

at com.sun.msv.verifier.jarv.FactoryImpl.compileSchema(FactoryImpl.java:98)

It complains that it cannot find the class com.sun.msv.datatype.xsd.AnyURIType, but that class is present in one of the jars. I am assuming some of those classes on the stack trace were "incorrectly" picked up from a module that comes from JBoss, thus loaded from another class loader, rather than from a jar in the web app's WEB-INF/lib. But which one can it be? (The orbeon.apache.xerces you see there is a re-rooted version of Apache Xerces, so we can be sure it has been loaded from the web app jars.) I have seen that I can exclude some modules in the jboss-deployment-structure.xml, as follows, but which on should I exclude? How to find out?

<jboss-deployment-structure>

<ear-subdeployments-isolated>true</ear-subdeployments-isolated>

</exclusions>

</deployment>

</jboss-deployment-structure>

Alex

1. Re: How to debug an incorrect module dependency in JBoss 7?

mreasy Oct 20, 2011 4:10 AM (in response to avernet)

I would also bet on a another ClassLoader having loaded the class before.
See this thread for a similar issue and have a look at Thomas Diesler's comment how to debug it: http://community.jboss.org/message/627330#627330
Actions
2. Re: How to debug an incorrect module dependency in JBoss 7?

avernet Oct 20, 2011 1:24 PM (in response to mreasy)

Hi Rico,

Thank you for the response. But I am not sure what suggestion in that thread you are referring to. You had a ClassCastException, casting to javax.servlet.Filter, which clearly could be loaded from a module that comes with JBoss. I have a NoClassDefFoundError, and what puzzles me is that I don't see how any of the classes in that stack trace could come from a module in JBoss. They should all come from the jars in the web app, including the one it can't find (com.sun.msv.datatype.xsd.AnyURIType). I also did a search in all the jars that come with JBoss, and none contains any com.sun.msv classes.

Alex
Actions
3. Re: How to debug an incorrect module dependency in JBoss 7?

mjdinsmore Oct 20, 2011 1:31 PM (in response to avernet)

Are you just deploying a WAR file, or an EAR file that lists the modules/components in there? It seems like there's a classpath problem and it's easier to figure out where it could be if we understood exactly how things are packaged.
Actions
4. Re: How to debug an incorrect module dependency in JBoss 7?

avernet Oct 20, 2011 2:51 PM (in response to mjdinsmore)

Michael,

I am deploying a war file. Now, looking at the MSV code, I am thinking that this due to something particular MSV is doing in DatatypeLibraryLoader:

https://github.com/orbeon/msv/blob/master/relaxngDatatype/src/org/relaxng/datatype/helpers/DatatypeLibraryLoader.java

Somehow this "old mess" works fine on Tomcat, all previous version of JBoss, and all the other applicaiton servers I got a chance to test this one so far, but not JBoss 7. But at this point, I'll have to differ figuring this out to another day.

Alex
Actions
5. Re: How to debug an incorrect module dependency in JBoss 7?

mjdinsmore Oct 20, 2011 3:12 PM (in response to avernet)
We're running into some of the same problems with some similar code we wrote that works fine in Tomcat and older versions of JBoss but do not work in JBoss 7.
.... String classname = toClassName(name); ClassLoader loader = Thread.currentThread().getContextClassLoader(); try { Class type = loader.loadClass(classname); if (type.isAnnotationPresent(this.annotation)) { this.classes.add(type); } } ....

I shouldn't be surprised though. This all boils down to the Apache Commons VFS code and seeing what changed and why. It used to behave like this:

jar:../lib/classes.jar!/META-INF/manifest.mf

but now it no longer adds the bang:

jar:../lib/classes.jar/META-INF/manifest.mf

among other changes. You might want to check out the JBoss Jira to review the progress on the JB7 issues.
1 of 1 people found this helpful
Actions
6. Re: How to debug an incorrect module dependency in JBoss 7?

avernet Oct 20, 2011 10:21 PM (in response to mjdinsmore)

Michael,

This is interesting: I am not following you; which part of that part you quoted is relying on the bang being there?

Alex
Actions
7. Re: How to debug an incorrect module dependency in JBoss 7?

mjdinsmore Oct 20, 2011 11:46 PM (in response to avernet)

If you take a look at http://commons.apache.org/vfs/ you'll see the VFS stuff. And if you continue reading, you'll see an example in this page (http://commons.apache.org/vfs/filesystems.html#Zip_Jar_and_Tar) that shows the exmaple with a bang (perhaps I should have said exclamation point). The code we had written assumed there would be the exclamation point after the jar name, but that is no longer the case with JBoss 7. So our code no longer works properly.

Our code, right or wrong, went through the list of file to scan for the annotated classes, and would introspect the jar when it came to it. Since we can't identify the jar like we used to (because there is no exclamation point), it would never find any of the annotated classes. The exclamation point is optional in the regex replace because JBoss VFS, in its infinite wisdom, decided to forego delimiting the boundary between jar and jar contents in vfszip: urls. I hope this clarifies things. You might want to browse through the VFS Jira issues to get some more info (more to be had there than the documentation, IMHO -- i.e. https://issues.jboss.org/browse/JBVFS-147.
1 of 1 people found this helpful
Actions
8. Re: How to debug an incorrect module dependency in JBoss 7?

avernet Oct 24, 2011 6:18 PM (in response to mjdinsmore)

Hi Michael,

This is very useful; thank you for sharing all those details.

Alex
Actions

Go to original post