CONFIGURATION FAILED! DTD factory class org.apache.xerces.impl.dv.dtd.DTDDVFactoryImpl does not extend from DTDDVFactory
Usually on OSX, but sometimes in other platforms as well. It's behavior is extremely inconsistent.
It will also inconsistently break when you deploy the opensocial-portlet (because that app has its own xercesImpl.jar).
The root causes has to do with Glassfish's bundling of Moharra (jsf-impl.jar)
jsf-impl.jar/META-INF/services/javax.servlet.ServletContainerInitializer calls FacesInitializer to automatically map any web app with FacesServlet to /faces/', '.jsf', and '*.faces'
That means every webapp will then call com.sun.faces.config.ConfigureListener which will eventually try to parse web.xml or other files within the webapp using one version of Xerces while the webapp's other version of Xerces will conflict and cause that exception.
Simply removing xerces doesn't fix the issue as the webapp will not know to load the proper xerces in other scenarios. It's as if Glassfish has a bug where it is not cleanly removing xerces sometimes but cleanly removing it othertimes (by removig, I mean abstracting it out from the webapp). So it's probably a OSGi / felix error wth Glassfish.
The temporary fix is to simply remove META-INF/services/javax.servlet.ServletContainerInitializer from jsf-impl.jar.
This will have the side effect of not automatically wiring every webapp for faces
Glassfish 3 will give this error:
CONFIGURATION FAILED! DTD factory class org.apache.xerces.impl.dv.dtd.DTDDVFactoryImpl does not extend from DTDDVFactory
Usually on OSX, but sometimes in other platforms as well. It's behavior is extremely inconsistent.
It will also inconsistently break when you deploy the opensocial-portlet (because that app has its own xercesImpl.jar).
The root causes has to do with Glassfish's bundling of Moharra (jsf-impl.jar)
jsf-impl.jar/META-INF/services/javax.servlet.ServletContainerInitializer calls FacesInitializer to automatically map any web app with FacesServlet to /faces/', '.jsf', and '*.faces'
That means every webapp will then call com.sun.faces.config.ConfigureListener which will eventually try to parse web.xml or other files within the webapp using one version of Xerces while the webapp's other version of Xerces will conflict and cause that exception.
Simply removing xerces doesn't fix the issue as the webapp will not know to load the proper xerces in other scenarios. It's as if Glassfish has a bug where it is not cleanly removing xerces sometimes but cleanly removing it othertimes (by removig, I mean abstracting it out from the webapp). So it's probably a OSGi / felix error wth Glassfish.
The temporary fix is to simply remove META-INF/services/javax.servlet.ServletContainerInitializer from jsf-impl.jar.
This will have the side effect of not automatically wiring every webapp for faces