CODEWITHSUNDEEP
javaglassfishglassfish-3earapplication-client
jportway
jportway

Reputation: 917

Deploying an ear containing an Application Client on Glassfish 3.1.2 throws exceptions

I'm asking this question just so I can answer it myself, because it's driven me nuts for two days and no one else should have to suffer as I have.

When deploying my ear, I get exceptions like this :


Exception while invoking class org.glassfish.appclient.server.core.AppClientServerApplication start method
org.jvnet.hk2.component.ComponentException: injection failed on org.glassfish.appclient.server.core.jws.JavaWebStartInfo.dch with class org.glassfish.appclient.server.core.jws.DeveloperContentHandler
    at org.jvnet.hk2.component.InjectionManager.error_injectionException(InjectionManager.java:284)
    at org.jvnet.hk2.component.InjectionManager.inject(InjectionManager.java:161)
    at org.jvnet.hk2.component.InjectionManager.inject(InjectionManager.java:93)
.
.
Caused by: org.jvnet.hk2.component.ComponentException: Failed to create class org.glassfish.appclient.server.core.jws.DeveloperContentHandler
.
.
Caused by: java.lang.AbstractMethodError: javax.xml.parsers.DocumentBuilderFactory.setFeature(Ljava/lang/String;Z)V
.
.

or sometimes like this :


Exception while loading the app : injection failed on org.glassfish.appclient.server.core.jws.JavaWebStartInfo.dch with class org.glassfish.appclient.server.core.jws.DeveloperContentHandler
org.jvnet.hk2.component.ComponentException: Failed to create class org.glassfish.appclient.server.core.jws.DeveloperContentHandler
    at com.sun.hk2.component.ConstructorCreator.create(ConstructorCreator.java:71)
    at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:80)
.
.
Caused by: java.lang.NoClassDefFoundError: Could not initialize class org.glassfish.appclient.server.core.jws.DeveloperContentHandler

The bug is utterly baffling, because ear files that work perfectly well on one machine can fail to deploy on another, and a server can appear to become "infected" by the problem and refuse to deploy ears that previously worked perfectly well. Clearing out caches and generated files doesn't make it go away.

Upvotes: 4

Views: 2455

Answers (2)

Frank
Frank

Reputation: 1489

The JDK defines the javax.xml.parsers.DocumentBuilderFactory interface and provides an default implementation. Service providers can replace the implementation class by setting a system property "javax.xml.parsers.DocumentBuilderFactory". When you deployed xerces it used this property to provide it's own implementation.

Snippet from javax.xml.parsers.DocumentBuilderFactory:

   public static DocumentBuilderFactory newInstance() {
    try {
        return (DocumentBuilderFactory) FactoryFinder.find(
            /* The default property name according to the JAXP spec */
            "javax.xml.parsers.DocumentBuilderFactory",
            /* The fallback implementation class name */
            "com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl");
    } catch (FactoryFinder.ConfigurationError e) {
        throw new FactoryConfigurationError(e.getException(),
                                            e.getMessage());
    }

}

All this applies as well to javax.xml.parsers.SAXParserFactory.

Choosing the Parser Implementation

If no other factory class is specified, the default SAXParserFactory class is used. To use a parser from a different manufacturer, you can change the value of the environment >variable that points to it. You can do that from the command line:

java -Djavax.xml.parsers.SAXParserFactory=yourFactoryHere [...]

The factory name you specify must be a fully qualified class name (all package prefixes >included). For more information, see the documentation in the newInstance() method of the >SAXParserFactory class.

http://docs.oracle.com/javase/tutorial/jaxp/sax/validation.html

Upvotes: 1

jportway
jportway

Reputation: 917

After hours and hours of fiddling with it I think I have the answer - the problem is caused by having a xerxes-impl jar file included in the ear lib folder. I suspect that through some class loading weirdness it is replacing the server's own xml parser. This accounts for the strange infection problem because the class path issues don't go away until the server is restarted. It's possible that the problem will manifest with any xml parser, but I haven't checked.

To solve the problem shut down glassfish, make sure the ear you're deploying doesn't have xerces in it, and then restart glassfish and deploy your new clean ear file. It should work. It did for me. Failing that, i think your only recourse is going to be blood sacrifice.

Upvotes: 3

Related Questions