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.
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.