I'm getting the following error message:
java.lang.ClassCastException: weblogic.xml.jaxp.RegistryDocumentBuilderFactory cannot be cast to javax.xml.parsers.DocumentBuilderFactory
I've gone through some forums researching this. They said to remove xml-apis.jar or that JAR files were conflicting. But even though I did all the suggested steps, I'm getting the same error.
It's always the xml-apis.jar. Remove them from your classpath (e.g. remove them from WEB-INF/lib of your webapp).
Remove xml-beans-1.xb2 to the lib directory. Modified the POM so it does not include that jar file with the following:
<dependency>
<groupId>xml-apis</groupId>
<artifactId>xml-apis</artifactId>
<version>1.0.b2</version>
<scope>provided</scope>
</dependency>
I think Banang is right. Forum http://forum.springsource.org/showthread.php?t=22597 describes solution for similar problem.
Typically such problems happen when there are several versions of the same class in class path while those versions are loaded by different class loaders. One version of DocumentBuilderFactory was loaded by system class loader, other by class loader of your enterprise application. When you are calling the XML parser the parent's version of the class is used. When you are casting yours private version is utilized. These versions are incompatible that causes ClassCastException.
The reason for this issue is you are having multiple jars with same class name in library.
Go to WEB-INF/lib and remove xml-apis-1.0.b2.jar and stax-api-1.0.1.jar or remove them from you pom.xml itself and you would be good to go.
I wanted make a slight addition to the previous answers to this question, in the event that anyone else is in the same situation I was. I had the same problem on our WebLogic 9.2 server due to my use of CXF 2.2.3. In addition to the removal of the xml-apis.jar mentioned previously, I also had to remove a xmlParserAPIs library.
As I am using Maven2 it was just a simple matter of adding another inclusion.
<!-- CXF -->
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-bundle</artifactId>
<version>${dependency.version.cxf}</version>
<scope>compile</scope>
<exclusions>
<exclusion>
<artifactId>xml-apis</artifactId>
<groupId>xml-apis</groupId>
</exclusion>
<exclusion>
<artifactId>xercesImpl</artifactId>
<groupId>xerces</groupId>
</exclusion>
<exclusion>
<artifactId>xmlbeans</artifactId>
<groupId>org.apache.xmlbeans</groupId>
</exclusion>
<exclusion>
<artifactId>xmlParserAPIs</artifactId>
<groupId>xerces</groupId>
</exclusion>
</exclusions>
</dependency>
Hope this helps someone!
We also has such trouble. The reason of error was in gwt library. Receipe: exlude all gwt client libraries from distr.
As for my case, I managed to solve this issue by removing xml-apis library and also upgrading an XML processing library:
From
org.apache.xmlbeans/xmlbeans/2.4.0
Into
org.apache.xmlbeans/xmlbeans/2.6.0
FYI, I'm using Weblogic 10.3.6.0.
Related
I want to use saxon to process xpath in a jira module.
Unit tests covering the problematic code were running fine in eclipse, so I have deployed the module, and ...
I have encountered the dreaded
java.lang.ClassCastException: org.apache.xerces.jaxp.SAXParserFactoryImpl cannot be cast to javax.xml.parsers.SAXParserFactory (see Dealing with "Xerces hell" in Java/Maven?)
I tried to exclude xml-apis from saxon dependencies, as it is suggested in https://answers.atlassian.com/questions/104121/i-m-blocked-help-cannot-be-cast-to-javax-xml-parsers-saxparserfactory
Now I got w3c.dom missing, which is strange, because I would bet my hat that it is existing somewhere in jira.
I added dom4j to pom dependencies nevertheless, and got
java.lang.NoClassDefFoundError: Could not initialize class net.sf.saxon.Configuration
With no indication of which class is missing.
Here is the code with the initial problem:
https://github.com/magwas/andreymarkelov-atlas-plugins-requestedfields/tree/feature/xsltfixes
the patch leading to current state is at http://pastebin.com/vwR43hHt
What would be the solution?
Okay, figured it out. I am not sure why, so an analysis would be welcome.
<dependency>
<groupId>net.sf.saxon</groupId>
<artifactId>Saxon-HE</artifactId>
<version>9.4</version>
<exclusions>
<exclusion>
<artifactId>xom</artifactId>
<groupId>xom</groupId>
</exclusion>
<exclusion>
<artifactId>dom4j</artifactId>
<groupId>dom4j</groupId>
</exclusion>
</exclusions>
</dependency>
Exception in thread "main" java.lang.IllegalAccessError: tried to access field org.slf4j.impl.StaticLoggerBinder.SINGLETON from class org.slf4j.LoggerFactory
at org.slf4j.LoggerFactory.<clinit>(LoggerFactory.java:60)
at org.hibernate.cfg.Configuration.<clinit>(Configuration.java:151)
at com.erp.utility.Hibernatesession.getSession(Hibernatesession.java:24)
at com.erp.dao.Country_Dao.getcountryByname(Country_Dao.java:88)
at com.erp.service.Country_Service.getcountryByname(Country_Service.java:36)
at com.erp.storedata.Store_Data.main(Store_Data.java:24)
Use a newer version of the slf4j-api.jar. There was a breaking change between version 1.5.5 and earlier and 1.5.6 and later. Use a version after 1.5.6, and that error should go away. For reference, see http://www.slf4j.org/faq.html#IllegalAccessError.
Please add following file on your project:
slf4j-log4j12.jar
remove the file slf4j-api.jar from your build path.
Finally resolved this problem in my SpringBoot application. If updating version is not helping this might help. Sometimes other libraries might bring different versions of this dependencies. These are the steps:
By error stack trace figure out which dependency is giving this issue
Get maven dependency plugin tree. Using this tree details find out if this library is coming as part of the some other dependency. In my case, the logback-classic and log4j-over-slf4j were giving this problem. They came together under spring-boot-starter-web
Use <exclusions><exclusion></exclusion></exclusions> in your pom.xml in that dependency for the libraries that giving this issue. In my case it looks like this:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
<exclusions>
<exclusion>
<artifactId>logback-classic</artifactId>
<groupId>ch.qos.logback</groupId>
</exclusion>
<exclusion>
<artifactId>log4j-over-slf4j</artifactId>
<groupId>org.slf4j</groupId>
</exclusion>
</exclusions>
</dependency>
References:
http://www.slf4j.org/faq.html#IllegalAccessError
http://www.slf4j.org/codes.html#multiple_bindings
I have an OSGi bundle that does some LDAP operations. It uses Apache Shared Directory to do these operations. I'm using Maven Bundle Plugin to build my bundle. For lack of time and resources, I have to go with in pom.xml, which includes Apache Shared Directory and other jars it depends on, in the generated bundle. One of the dependencies is Xerces, followed by Xml apis. When I include these two jars in the bundle, Karaf throws a ClassCastException:
java.lang.ClassCastException: org.apache.xerces.jaxp.DocumentBuilderFactoryImpl cannot be cast to javax.xml.parsers.DocumentBuilderFactory
Further investigation revealed that the class javax.xml.parsers.DocumentBuilderFactory is being loaded from two jars - Xml-apis.jar that I included in my bundle and the JRE's rt.jar, which is causing the ClassCastException. Since this class is being loaded from rt.jar, I figured I don't need to include Xml-apis.jar in my bundle and removed it. However, now I see the ClassNotFoundException:
Caused by: java.lang.ClassNotFoundException: javax.xml.parsers.DocumentBuilderFactory not found by mybundle.ldap [149]
at org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:812)[org.apache.felix.framework-3.2.2.jar:]
at org.apache.felix.framework.ModuleImpl.access$400(ModuleImpl.java:72)[org.apache.felix.framework-3.2.2.jar:]
at org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1807)[org.apache.felix.framework-3.2.2.jar:]
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)[:1.6.0_35]
So, if I include the xml-apis.jar, I get the ClassCastException. If I don't include it, I get the ClassNotFoundException. Is there a way I can resolve this issue? Any help would be appreciated.
Import the package javax.xml.parsers.
have you tried commenting out the line
javax.xml.parsers, \
in the etc/jre.properties file? This should prevent loading of the class from rt.jar.
Problem solved!! (at least for me)
You can find a very good explanation of the problem in this link:
Dealing with "Xerces hell" in Java/Maven?
As you can read, actually, it's a problem of Xerces compatibility. Maybe you don't use Xerces, but probably you are using a library that use Xerces.
The solution in my case was to use an old version of xerces (lucene-xercesImpl) and exclude any reference to xml-apis o xerces:
<properties>
<ver.jena>2.10.1</ver.jena>
<ver.jena-sdb>1.3.6</ver.jena-sdb>
<ver.h2>1.3.173</ver.h2>
</properties>
<dependencies>
<dependency>
<groupId>org.apache.jena</groupId>
<artifactId>jena-sdb</artifactId>
<version>${ver.jena-sdb}</version>
<exclusions>
<exclusion>
<groupId>xml-apis</groupId>
<artifactId>xml-apis</artifactId>
</exclusion>
<exclusion>
<groupId>xerces</groupId>
<artifactId>xercesImpl</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.apache.lucene</groupId>
<artifactId>lucene-xercesImpl</artifactId>
<version>3.5.0</version>
</dependency>
<dependency>
<groupId>org.apache.jena</groupId>
<artifactId>apache-jena-libs</artifactId>
<type>pom</type>
<version>${ver.jena}</version>
<exclusions>
<exclusion>
<artifactId>commons-codec</artifactId>
<groupId>commons-codec</groupId>
</exclusion>
<exclusion>
<groupId>org.apache.jena</groupId>
<artifactId>jena-tdb</artifactId>
</exclusion>
</exclusions>
</dependency>
Hope this help!
When minimising yui with 2.4.6, I get this problem:
java.lang.StringIndexOutOfBoundsException: String index out of range: 232
at java.lang.String.substring(String.java:1934)
at com.yahoo.platform.yui.compressor.JavaScriptCompressor.printSourceString(JavaScriptCompressor.java:267)
at com.yahoo.platform.yui.compressor.JavaScriptCompressor.parse(JavaScriptCompressor.java:330)
at com.yahoo.platform.yui.compressor.JavaScriptCompressor.<init>(JavaScriptCompressor.java:533)
It works when started through my IDE but when deployed to jboss it doesn't. This place: http://yuilibrary.com/forum/viewtopic.php?p=20086 has some discussion of the same problem.
Apparently the issue is around org/mozilla/javascript/Parser being in the two jars that are pulled in from my maven config:
<dependency>
<groupId>com.yahoo.platform.yui</groupId>
<artifactId>yuicompressor</artifactId>
<version>2.4.6</version>
</dependency>
Is there any way I can solve this using maven exclusions etc. or by upgrading my version of YUI. It seems daft that it just doesn't work and I don't want to have to write a custom classloader.
Please help!
Workaround: For JBoss AS 7.1.1.Final and YUICompressor 2.4.7
Exclude rhino from dependency:
<dependency>
<groupId>com.yahoo.platform.yui</groupId>
<artifactId>yuicompressor</artifactId>
<version>${yuicompressor.version}</version>
<exclusions>
<exclusion>
<groupId>rhino</groupId>
<artifactId>js</artifactId>
</exclusion>
</exclusions>
</dependency>
Why? See https://github.com/greenlaw110/greenscript/pull/29#issuecomment-4017147
Note: if you have a rhino in classpath by some other way, so seems like you'll get this error again.
I solved this problem by repackaging yuicompressor myself to include most of the rhino source. See my reply to Howard M. Lewis Ship.
The repackaged source can be found here : http://viscri.co.uk/labs/tapestry/yuicompressor-rhino-bugfix-5.0.jar. Just add this to your pom:
<dependency>
<groupId>yuicompressorbugfix</groupId>
<artifactId>yuicompressor-rhino-bugfix</artifactId>
<version>5.0</version>
</dependency>
If you don't run your own version of nexus, you'll have to install it on the machine that you want to build on. This is the command you need I think: http://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html
You'll also need to exclude the yuicompressor version that tapestry pulls in:
<dependency>
<groupId>org.apache.tapestry</groupId>
<artifactId>tapestry-yuicompressor</artifactId>
<version>5.3.2</version>
<exclusions>
<exclusion>
<groupId>com.yahoo.platform.yui</groupId>
<artifactId>yuicompressor</artifactId>
</exclusion>
</exclusions>
This should work.
The selected answer's (as of 9/26/2014) jar doesn't exist anymore.
So, I created a fork of yuicompressor where entire rhino package is embedded into the yuicompressor package and namespaced it under yui.
https://github.com/timothykim/yuicompressor
Just clone the repo and run ant to obtain the jar.
Hope this helps anyone else who stumbles unto this problem.
Really, you're having class loader problems in JBoss?
You're going to have to do some kind of exclusion on the competing rhino JAR file. Why is Rhino on the classpath? It may be an optional feature of JBoss you can turn off and avoid the conflict that way.
Will adding a MANIFEST.MF file with Class-Path attribute to META-INF directory inside EAR influence the order of loading of JARs located in APP-INF/lib under WebLogic 8.1?
I don't believe you can control the APP-INF/lib order via ClassPath attribute of MANIFEST.MF.
I've done this a couple different ways, depending on the client.
Add the patch jar to the system classpath for WLS. If you examine domain/bin/setDomainEnv.sh (or .cmd) there should pre, post, patch classpath environment variables. You could try to add your patch jar to the classpath here. This makes it available for all apps, which might not be what your client wants.
Patch somejar.jar & name it somejar-patched.jar. Replace the jar in APP-INF/lib with the "-patched" version.
I thought the class loader read JARs as they're required by your application.
I have two questions for you:
Why are you still using WebLogic 8.1? It's off support now, and the current version is 10.x. You're two versions behind. Is this a legacy app that hasn't migrated yet? You'll get a big boost by upgrading, because you'll be using JDK 5 or 6 with the -server option. I'd recommend it.
Why should you care about the order of loading? It should be immaterial to your app how the container loads and manages the beans.
UPDATE:
That sounds different, almost as if you were having conflicts with server JARs. There's that prefer-web-inf-classes setting for that situation. Is that what you mean?
I agree with duffymo
You shouldn't have to worry about the order of class loading, if this is due to conflicting classes you can always exclude the conflicting classes from Jars using Maven or a similar tool.
For instance this is a very simple example of adding jersey-spring4 jar but I'm excluding its dependencies so I can use a different version of the spring framework library.
<dependency>
<groupId>org.glassfish.jersey.ext</groupId>
<artifactId>jersey-spring4</artifactId>
<exclusions>
<exclusion>
<artifactId>spring-web</artifactId>
<groupId>org.springframework</groupId>
</exclusion>
<exclusion>
<artifactId>spring-aop</artifactId>
<groupId>org.springframework</groupId>
</exclusion>
<exclusion>
<artifactId>spring-context</artifactId>
<groupId>org.springframework</groupId>
</exclusion>
<exclusion>
<artifactId>spring-beans</artifactId>
<groupId>org.springframework</groupId>
</exclusion>
</exclusions>
</dependency>