We Keep Coding

How to fix 'javax.xml.parsers.FactoryConfigurationError on every second server startup'

I'm writing a web application which uses JAXB and JAX-RS. The content-type used for getting/sending data to the server is XML. The web application runs in a GlassFish server(4.1.2/ 5), the JDK used is 1.8.
The problem is that the internal SAXParser allows doctype declarations which makes XEE-Attacks possible. I'm not able to inject the specific feature into the SAXParserFactory, so i built a wrapper for the SAXParserFactory, which sets the feature. The SAXParserFactory is registered using the system properties.
System.setProperty("javax.xml.parsers.SAXParserFactory","de.mycompany.sdk.parser.SAXParserFactoryWrapper");
Unfortunately, the server throws a ClassNotFoundException on every second startup, otherwise the application behaves normal.
Has anyone ideas how to fix it?
I've also tried to include the jar into the class path or specify it using the manifest, but did not work neither.
I get the following error:
javax.xml.parsers.FactoryConfigurationError: Provider de.mycompany.sdk.parser.SAXParserFactoryWrapper not found
at javax.xml.parsers.FactoryFinder.newInstance(FactoryFinder.java:200)
at javax.xml.parsers.FactoryFinder.newInstance(FactoryFinder.java:152)
at javax.xml.parsers.FactoryFinder.find(FactoryFinder.java:232)
at javax.xml.parsers.SAXParserFactory.newInstance(SAXParserFactory.java:127)
at com.sun.enterprise.deployment.io.DeploymentDescriptorFile.getSAXParser(DeploymentDescriptorFile.java:125)
at com.sun.enterprise.deployment.io.DeploymentDescriptorFile.read(DeploymentDescriptorFile.java:305)
at com.sun.enterprise.deployment.io.DeploymentDescriptorFile.read(DeploymentDescriptorFile.java:245)
Caused by: java.lang.ClassNotFoundException: de/mycompany/sdk/parser/SAXParserFactoryWrapper
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at javax.xml.parsers.FactoryFinder.getProviderClass(FactoryFinder.java:124)
at javax.xml.parsers.FactoryFinder.newInstance(FactoryFinder.java:188)
... 56 more```

ClassNotFoundException
can occur if you have multiple versions of a class (de.mycompany.sdk.parser.SAXParserFactoryWrapper in this case) in your class path. This generally happens when you have multiple versions of the same library in your classpath.

Thanks for your help! I found a solution for my problem. I deployed the application using the GlassFish CLI and it works! The previous tries were done using NetBeans. It seems that NetBeans does anything different during the startup or shutdown process of the GlassFish server wich involves the exception.

Classloader issues when looking up ejb jndi names tomcat 6

I am in the process of migrating a legacy application from weblogic to Tomcat 6.
The application needs to access ejbs; to achieve that, I added wlclient.jar to the classpath.
When the methods in the legacy jars responsible for communicating with the ejbs are called, I get the following exception :
javax.naming.NamingException: Unhandled exception in lookup
[Root exception is org.omg.CORBA.MARSHAL: vmcid: SUN minor code: 211 completed: Maybe]
which cause is :
Caused by: java.lang.IllegalArgumentException: interface com.xxx.xxx.InterfaceName is not visible from class loader
at java.lang.reflect.Proxy.getProxyClass(Proxy.java:353)
at java.lang.reflect.Proxy.newProxyInstance(Proxy.java:581)
at weblogic.iiop.ProxyDesc.readResolve(ProxyDesc.java:45)
That Interface seems to be used to define the method called from the client to return some informations from the server where the ejbs are deployed.
When running with verbose:class, I find that the Interface is actually loaded from the local jar. The corresponding interface on the server is loaded too :
[Loaded com.xx.xx.InterfaceName_t3s99q_InterfaceNameIntf from http://192.168.x.xx:port/path/classes/]
Even though I do not have any idea how that works internally, I assumed the lookup had gone well since it finds the correct class on the server.
When putting breakpoints in Proxy.getProxyClass, I found the used classloader when the exception occurs was a Launcher$AppClassLoader; the URL's it used to lookup were those in my local classpath (a.k.a. src/main/java and such) and not the webapp's path (a.k.a. WEB-INF/lib and such).
So my question is : is it possible that the wrong ClassLoader gets used for that specific lookup (local one instead of Tomcat's webapp level one)?
Can I specify a specific ClassLoader?
Am I looking in the completely wrong direction to resolve that issue ?

Well I lost 1.5 days on this, so I'll post an answer hoping it will eventually be useful to someone.
The problem was that I included wlclient.jar in eclipse classpath, and since the oracle implementation uses super.getClass().getClassLoader() , it would return the ClassLoader used to load the Class in which the call is made a.k.a. the local ClassLoader and not the one from the Webapp, so it did not have visiblity of the webapp dependencies.
I updated my project to include the jar in WEB-INF/lib so it would be loaded by the webapp and thus super.getClass().getClassLoader() would return the right ClassLoader.
An other possibility would have been to modify that line to use Thread.currentThread.getContextClassLoader instead.

WSDL parsing exception creating Webservice client with CXF JaxWSClientFactoryBean

I've written some code to create and run webservice client using CXF. I used JaxWsClientFactoryBean (not sure it's the best solution) to create client from .wsdl file.
The goal here was to do this programmatically avoiding Spring etc. Just pure code with Java and CXF.
JaxWsClientFactoryBean cfb = new JaxWsClientFactoryBean();
cfb.setAddress(getServiceProperty(intClass, PROPERTY_KEY_URL_SUFFIX));
cfb.setServiceClass(intClass);
cfb.setOutInterceptors(getOutInterceptors(intClass));
cfb.setServiceName(SERVICE_NAME);
cfb.setWsdlURL("classpath:wsdl/" + intClass.getSimpleName() + ".wsdl");
cfb.setEndpointName(ENDPOINT_NAME);
Client client = cfb.create();
ClientProxy cp = new ClientProxy(client);
I intService = (I)
Proxy.newProxyInstance(intClass.getClassLoader(), new Class[] { intClass }, cp);
I'm really not sure if this is done correctly, but it works when I run this code locally and when I deploy it on Tomcat.
Unfortunatelly I need to run this code on Weblogic and this results in strange exception:
Caused by: javax.wsdl.WSDLException: WSDLException: faultCode=PARSER_ERROR: org.w3c.dom.DOMException: HIERARCHY_REQUEST_ERR: An attempt was
made to insert a node where it is not permitted.
at org.apache.cxf.wsdl11.WSDLManagerImpl.loadDefinition(WSDLManagerImpl.java:235)
at org.apache.cxf.wsdl11.WSDLManagerImpl.getDefinition(WSDLManagerImpl.java:186)
at org.apache.cxf.wsdl11.WSDLServiceFactory.<init>(WSDLServiceFactory.java:92)
... 26 more
Caused by: org.w3c.dom.DOMException: HIERARCHY_REQUEST_ERR: An attempt was made to insert a node where it is not permitted.
at com.sun.org.apache.xerces.internal.dom.ParentNode.internalInsertBefore(ParentNode.java:356)
at com.sun.org.apache.xerces.internal.dom.ParentNode.insertBefore(ParentNode.java:284)
at com.sun.org.apache.xerces.internal.dom.CoreDocumentImpl.insertBefore(CoreDocumentImpl.java:399)
at com.sun.org.apache.xerces.internal.dom.NodeImpl.appendChild(NodeImpl.java:235)
at org.apache.cxf.staxutils.StaxUtils.readDocElements(StaxUtils.java:1019)
at org.apache.cxf.staxutils.StaxUtils.readDocElements(StaxUtils.java:939)
at org.apache.cxf.staxutils.StaxUtils.read(StaxUtils.java:866)
at org.apache.cxf.wsdl11.WSDLManagerImpl.loadDefinition(WSDLManagerImpl.java:226)
... 28 more
This happens during application deployment. It looks like there is something wrong with .wsdl file, but wait... It was working on Tomcat!
I think that there could be some difference in com.sun.org.apache.xerces.* classes implementation within Weblogic with its JRockit VM and standard JVM, but I have no idea how to solve it.
I spent many hours trying differend ways of client creation. Most of them worked locally and in Tomcat, but none on WebLogic.
Any hints what to try next? I'm kinda tired of this topic :D

I agree with your suspicion that the problem is related to the used version of Xerces. The stacktrace shows that the Sun implementation of Xerces which is derivative of the Apache Xerces is used in your case.
Please check the Apache CFX Application Server Configuration Guide instructions related to WebLogic.
WebLogic ClassLoading
In WebLogic Server, any .jar file present in the system classpath is loaded by the WebLogic Server system classloader. All applications running within a server instance are loaded in application classloaders which are children of the system classloader. In this implementation of the system classloader, applications cannot use different versions of third-party jars which are already present in the system classloader. Every child classloader asks the parent (the system classloader) for a particular class and cannot load classes which are seen by the parent.
For example, if a class called com.foo.Baz exists in both $CLASSPATH as well as the application EAR, then the class from the $CLASSPATH is loaded and not the one from the EAR. Since weblogic.jar is in the $CLASSPATH, applications can not override any WebLogic Server classes.
In order to use an alternate version of Xerces you have to create a FilteringClassLoader.
Usage of FilteringClassLoader
The FilteringClassLoader provides a mechanism for you to configure deployment descriptors to explicitly specify that certain packages should always be loaded from the application, rather than being loaded by the system classloader. This allows you to use alternate versions of applications such as Xerces and Ant.
The FilteringClassLoader sits between the application classloader and the system. It is a child of the system classloader and the parent of the application classloader. The FilteringClassLoader intercepts the loadClass(String className) method and compares the className with a list of packages specified in weblogic-application.xml file.
In conclusion, check the steps included in the Apache CFX Application Server Configuration Guide and take care to explicitly specify that the org.apache.xerces.* package is loaded from the application, rather than being loaded from the system classloader.
For example the weblogic-application.xml file in the META-INF should look like:
<?xml version="1.0" encoding="UTF-8"?>
<weblogic-application xmlns="http://www.bea.com/ns/weblogic/90">
<application-param>
<param-name>webapp.encoding.default</param-name>
<param-value>UTF-8</param-value>
</application-param>
<prefer-application-packages>
<package-name>javax.jws.*</package-name>
<package-name>org.apache.xerces.*</package-name>
</prefer-application-packages>
</weblogic-application>
I hope this helps.

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.

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.

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

XPath class resolution in JBoss5

I'm having a hard time figuring out where the problem is coming from, so I'm posting this in the hopes that others might have found something similar to this elsewhere and are kind enough to share their insight.
I'm using a JBoss 5.0.1.GA application server running on top of a Sun Java 1.6.0-13 JDK. For the WAR file in the generated Web Service, I use a Axis2 1.4 WS engine whose JAR files are inserted by Eclipse Galileo into the project's WEB-INF/lib directory when creating the Webservice from the given "worker" class in the Dynamic Web Project. The relevant code snippet follows:
String sUrl = "http://example.com/datafile.xml";
String sPath = "/some/xpath/string";
InputStream input = new URL(sUrl).openStream();
InputSource source = new InputSource(input);
DocumentBuilderFactory docFact = DocumentBuilderFactory.newInstance();
docFact.setNamespaceAware(false);
DocumentBuilder parser = docFact.newDocumentBuilder();
Document doc = parser.parse(source);
XPath xpath = XPathFactory.newInstance().newXPath();
// error occurs here:
String result = (String) xpath.evaluate(path,doc,XPathConstants.STRING);
input.close();
This is the error I'm getting from the JBoss log:
java.lang.LinkageError: loader constraint violation: when resolving field "STRING" the class loader (instance of org/jboss/classloader/spi/base/BaseClassLoader) of the referring class, javax/xml/xpath/XPathConstants, and the class loader (instance of <bootloader>) for the field's resolved type, javax/xml/namespace/QName, have different Class objects for that type
I could use the XPath.evaluate(String,Document) — however there are occasions where I need to get (for example) a XPathConstants.NODESET instead, so it's a no-go. I have also tried to fumble a little by littering some jboss-web.xml files here and there in the WAR file, but with no effect.
What I'm trying to understand is:
Where could the error be coming from? The JBoss class loader? Some weird interaction between JBoss and the Sun JDK? Some weirdness introduced by Eclipse when creating the Web Service? Maybe some confusion introduced by the Axis2 libraries deployed within the WAR?
I've found instances of compiled class files in what looks like a triple-whammie:
Sun JDK (file rt.jar);
JBoss libraries ($JBOSS_HOME/lib/endorsed/stax-api.jar); and
Axis2-deployed libraries ($JBOSS_HOME/server/deploy/MyProject.ear/MyProject.war/WEB-INF/lib/axis2-saaj-api-1.4.jar and woden-impl-dom-1.0M8.jar).
How exactly am I supposed to configure JBoss to tell it which classes it's OK to load from "other" libraries from? Specifically, the jaxax.xml.namespace.QName is is causing the grief.
Thank you in advance.

JBoss will throw a LinkageError when the application's classpath contains classes which JBoss considers "protected", i.e. it does not permit the application to contain its own copies of certain key APIs.
In this case, it looks like your appcontains its own copies of the javax.xml.xpath API, and possibly some others as well, as you mentioned.
You need to remove anything from your EAR/WAR's lib directories that clashes with JBoss's own libraries (e.g. axis2-saaj-api-1.4.jar).

It seems that the problem was solved by removing the javax.xml.namespace.* package and respective classes from the deployed Axis2 JAR files. Namely, using Axis2 1.4.1 (instead of 1.4), I repackaged these JAR files:
axis2-saaj-api-1.4.1.jar, by removing javax.xml.namespace
woden-impl-dom-1.0M8.jar, by removing javax
Also, Eclipse is extremely picky at the project configuration. So far, I've found that the Project Facet for the Dynamic Web Project has to be created with a Dynamic Web Module of version 2.4 (and not 2.5 as it suggests by default), but with a Java version 6 (same as the branch of the used JDK). I don't know why this happens, I suppose the Dynamic Web Module version 2.4 tying up by default with Java 1.4 in Eclipse is where all the confusion comes from. Some googling led me to believe that package javax.xml didn't become incorporated into the JDK until Java 5 or Java 6 -- hence the possible mixup! However, I'm not knowledgeable enough to investigate if the problem comes from how Eclipse packages the archive files for deployment so this is just a suspicion I have so far.