Related
So I have this springboot application which I'm migrating from a WAS to a springboot setup. And I have a couple of JSPs which has to be configured. To accomodate these I added the following dependencies:
<dependency>
<groupId>org.apache.tomcat.embed</groupId>
<artifactId>tomcat-embed-jasper</artifactId>
<version>9.0.22</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>jstl</artifactId>
<scope>provided</scope>
</dependency>
The application already came with the following dependency which is being used throughout the application:
<dependency>
<groupId>com.ibm</groupId>
<artifactId>com.ibm-jaxrpc-client</artifactId>
<version>6.0</version>
</dependency>
The issue I'm facing is that both these dependencies (jaxrpc-client and tomcat-embed-jasper) have javax.servlet.ServletContext classes in them which is causing the following error:
The method's class, javax.servlet.ServletContext, is available from the following locations:
jar:file:/C:/Users/.m2/repository/com/ibm/com.ibm-jaxrpc-client/6.0/com.ibm-jaxrpc-client-6.0.jar!/javax/servlet/ServletContext.class
jar:file:/C:/Users/.m2/repository/org/apache/tomcat/embed/tomcat-embed-core/9.0.30/tomcat-embed-core-9.0.30.jar!/javax/servlet/ServletContext.class
It was loaded from the following location:
file:/C:/Users/.m2/repository/com/ibm/com.ibm-jaxrpc-client/6.0/com.ibm-jaxrpc-client-6.0.jar
Action:
Correct the classpath of your application so that it contains a single, compatible version of javax.servlet.ServletContext
I can't afford to remove any of these dependencies. jaxrpc-client is being referenced in the code already in too many places and I need tomcat-embed-jasper to render my jsp pages. I can't exclude the ServletContext class since its not a dependency(If I'm not wrong about the concept of exclusion). Please help with with a way forward with this issue.
I'm not familiar with IBM's jaxrpc client, but I assume, you have this exception in runtime, when trying to load the application.
In this case consider the following approaches:
Use another jax-rpc client library
Consider Loading the code that uses this library with the different class-loader (you'll have to create one classloader for this) to avoid the clash
Kind of paraphrasing the second option. You can "play" (override the order of loading of specific classes) with spring boot classloader as described in this article
I know, this is too general answer, but hopefully its still helpful.
The first solution is by far the easiest way I can think of.
The second solution is doable, however it pretty much depends on how exactly the code that uses the jax rpc client is loaded and used.
When running a project built by maven with the following dependencies:
<dependency>
<groupId>org.eclipse.persistence</groupId>
<artifactId>javax.persistence</artifactId>
<version>2.2.0</version>
</dependency>
<dependency>
<groupId>org.eclipse.persistence</groupId>
<artifactId>eclipselink</artifactId>
<version>2.7.0</version>
</dependency>
I get the following error at runtime:
java.lang.SecurityException: class "javax.persistence.Cacheable"'s signer information does not match signer information of other classes in the same package
The javax.persistence-2.2.0 artifact is signed and contains the javax.persistence.Cacheable.class annotation, while the eclipselink-2.7.0 artifact is not signed and also contains the same java class annotation.
How can this be fixed?
Edit
Replacing the javax.persistence artifact version 2.2.0 by the version 2.1.1 fixes the problem (this one is not signed), but I'm not sure it's a normal situation.
Thanks Stéphane - the edit at the end of your question helped me "fix" the same problem. For anyone else who hits this as well - here is an expanded answer. This is what you need to "fix" things in your pom (until Eclipse fix things properly):
<!-- See https://stackoverflow.com/q/45870753 -->
<dependency>
<groupId>org.eclipse.persistence</groupId>
<artifactId>eclipselink</artifactId>
<version>2.7.0</version>
<exclusions>
<exclusion>
<groupId>org.eclipse.persistence</groupId>
<artifactId>javax.persistence</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.eclipse.persistence</groupId>
<artifactId>javax.persistence</artifactId>
<version>2.1.1</version>
</dependency>
This pulls in eclipselink but excludes the javax.persistence dependency that it tries to pull in and replaces it with an earlier version of javax.persistence that doesn't have the signing issue.
Aside: javax.persistence version 2.2.0 is explicitly pulled in, in the pom fragment shown in the original question, despite already being a transitive dependency of eclipselink.
Explanation
Summary - the eclipselink artifact depends on javax.persistence and both contain classes that are in the package javax.persistence. However the javax.persistence jar is signed while the eclipselink one is not. So the Java runtime will complain, when loading a class from the package javax.persistence in the eclipselink jar, that it's lack of signing doesn't match with classes already loaded from the same package in the javax.persistence jar.
Details - if I put a breakpoint in java.util.concurrent.ConcurrentHashMap.putIfAbsent(K, V) with condition "javax.persistence".equals(arg0) then I see that javax.persistence is mapped to the following CodeSource value:
(file:/Users/georgehawkins/.m2/repository/org/eclipse/persistence/javax.persistence/2.2.0/javax.persistence-2.2.0.jar [
[
Version: V3
Subject: CN="Eclipse Foundation, Inc.", OU=IT, O="Eclipse Foundation, Inc.", L=Ottawa, ST=Ontario, C=CA
Signature Algorithm: SHA256withRSA, OID = 1.2.840.113549.1.1.11
...
I.e. javax.persistence-2.2.0.jar is signed by the Eclipse Foundation and contains classes in the package javax.persistence. This jar is pulled in when some part of my application (actually something deep in Spring logic) tries to load javax.persistence.EntityManagerFactory.
If I then put a breakpoint in java.lang.ClassLoader.checkCerts(String, CodeSource) on the throw new SecurityException line I then see that it hits this line when the passed in CodeSource is:
(file:/Users/georgehawkins/.m2/repository/org/eclipse/persistence/eclipselink/2.7.0/eclipselink-2.7.0.jar <no signer certificates>)
I.e. eclipselink-2.7.0.jar also contain classes that are in the javax.persistence package but it is unsigned so a clash occurs that results in a SecurityException being thrown. This happens when something (also deep in Spring logic) tries to load javax.persistence.PersistenceUtil.
If I look at the output of mvn dependency:tree I see that this mismatch seems to be down to eclipselink itself - it is pulling in org.eclipse.persistence:javax.persistence:jar:2.2.0 itself. I.e. it isn't some clash with some other dependency:
[INFO] | \- org.eclipse.persistence:eclipselink:jar:2.7.0:compile
[INFO] | +- org.eclipse.persistence:javax.persistence:jar:2.2.0:compile
[INFO] | +- org.eclipse.persistence:commonj.sdo:jar:2.1.1:compile
[INFO] | +- javax.validation:validation-api:jar:1.1.0.Final:compile
[INFO] | \- org.glassfish:javax.json:jar:1.0.4:compile
I've logged this now at bugs.eclipse.org - see bug 525457.
To fix this issue, put in the correct JPA 2.2 compliant dependency for EclipseLink 2.7.x, in your maven pom file, as:
<dependency>
<groupId>org.eclipse.persistence</groupId>
<artifactId>org.eclipse.persistence.jpa</artifactId>
<version>2.7.1</version>
</dependency>
eclipselink.jar as such is designed as all-in-one bundle, not osgi enabled jar containing all partsof eclipselink project (ie sdo, oracle db specific stuff, dbws, nosql..) with ability to run with jpa api 2.0 on the classpath - at least in 2.x versions. In many cases this is not needed and proper components can be used instead, such as org.eclipse.persistence.jpa, org.eclipse.persistence.oracle etc. For the full list see ie: http://search.maven.org/#search%7Cga%7C1%7Corg.eclipse.persistence
This strange situation still seems to exist, in my case not using Maven, just trying to get a simple JPA example to run (and it is really frustrating if you need hours just to achieve that).
With 2.7.4 from January, this error occurs if you put the eclipselink.jar and jakarta.persistence_2.2.2.jar from the zip on the classpath.
In the end solution was to change order on the classpath: first the jakarta-persistence and only after that the eclipselink-jar.
So all javax.persistence classes are taken from jakarta-jar and not partly of the eclipselink-jar (if included there).
So I really wonder various things.
The eclipselink package should be all-in-one? But it is not. Some javax.persistence classes are contained. Others not - basic classes to be used in JPA code like EntityManager. Of course, together with the jakarta-jar included in the zip it is complete - but you may not use the two jars together with the "wrong" order on the classpath!? I really consider this a bug - or at least there should be a HUGE hint about this in the package then.
What is the org.eclipse.persistence.jpa-2.7.4.jar from Maven that is suggested here? It does not have the problems of the eclipselink.jar yes, not this error message. But then it also just seems not to include the Eclipselink JPA implementation, at least running with it I got error that persistence-unit referenced in code does not exist (same persistence.xml working with eclipselink.jar).
Strange situation.
My project was working on JDK-8, but stopped to work when I upgraded it to openJDK-11.
I solved it excluding the jpa-persistence module, and adding again on the version 2.2:
dependencies.create('org.eclipse.persistence:eclipselink:2.7.4') {
exclude module: "javax.persistence"
},
'javax.persistence:javax.persistence-api:2.2', //add it again, manually
'org.eclipse.persistence:org.eclipse.persistence.asm:2.7.4',
'org.eclipse.persistence:org.eclipse.persistence.antlr:2.7.4',
'org.eclipse.persistence:org.eclipse.persistence.moxy:2.7.4',
'org.eclipse.persistence:org.eclipse.persistence.core:2.7.4'
I fixed this by switching the order in which the jars appear in the classpath. In my case, I'm using Tomcat and had to modify catalina.properties to put javax before eclipselink.
Obinna's answer is correct; I guess that there was an issue with eclipselink 2.7.x –as George indicated. I had a similar issue when upgrading eclipselink, but it was just wrong artefacts. The initially described issue seems to be a result of externally referencing javax.persistence level - it is definitely not necessary.
Proper maven configuration can be found in eclipselink wiki:
https://wiki.eclipse.org/EclipseLink/Maven
I also run into this problem, with my case being a bit different, in that I am not using Maven. However, I place an answer here, as it might give people an idea about how to deal with this in their own situation. After all, the title is about this mismatch, in general, one sub-case being when using Maven.
I am using eclipselink in a NetBeans project. Initially, I was placing both the the eclipselink jar file (eclipselink-2.7.0.jar) and the needed org.eclipse.persistence jar files as external libraries to my project. Comments by Sergey and entreprenr above are what actually lead me to solve my problem. What I had to do was create a new library (Tools->Libraries->New Library...) which does not contain the eclipselink jar file (i.e. eclipselink-2.7.0.jar is not added in the library), only the specific org.eclipse.persistence jar files that are necessary for the project, e.g. org.eclipse.persistence.antlr-2.7.0.jar, org.eclipse.persistence.asm-2.7.0.jar, org.eclipse.persistence.core-2.7.0.jar, org.eclipse.persistence.jpa.modelgen.processor-2.7.0.jar, org.eclipse.persistence.jpa-2.7.0.jar, etc. I then added this library to my project and the exception vanished.
Of course, I also had to replace all org.eclipse.persistence jar files on my server with their 2.7.0 version and also replace the javax.persistence.jar with its 2.2.0 version (I use payara, so these are located under <payara_home>\glassfish\modules).
I'm using gradle in my project build and to solve the OP's problem, which I had as well, I finally used the following working setup.
dependencies {
testImplementation(group: 'org.eclipse.persistence', name: 'eclipselink', version: '2.7.4') {
exclude group: 'javax.validation', module: 'validation-api'
exclude group: 'org.eclipse.persistence', module: 'javax.persistence'
exclude group: 'org.eclipse.persistence', module: 'commonj.sdo'
exclude group: 'org.eclipse.persistence', module: 'jakarta.persistence'
}
testImplementation(group: 'org.eclipse.persistence', name: 'org.eclipse.persistence.jpa', version: '2.7.4') {
exclude group: 'org.eclipse.persistence', module: 'jakarta.persistence'
}
}
Instead of "testImplementation" you can of course use any dependency type you want or need.
After reading Sergey's comment I've improved this by just using:
dependencies {
testImplementation group: 'org.eclipse.persistence', name: 'org.eclipse.persistence.jpa', version: '2.7.4'
}
I think the last one is the best solution.
Because I could not find an answer for this problem when only using a Tomcat and this thread is often linked with this problem, I am going to post my solution here:
Since the signature is in the MANIFEST.MF you can change the signatures in the .jar files using 7zip or WinRAR to open them or simply delete them from the META-INF files of both .jar's and then import the changed files to your IDE.
A useful thread for the Signature-Mismatch-Problem is this thread: Java SecurityException: signer information does not match
When running a project built by maven with the following dependencies:
<dependency>
<groupId>org.eclipse.persistence</groupId>
<artifactId>javax.persistence</artifactId>
<version>2.2.0</version>
</dependency>
<dependency>
<groupId>org.eclipse.persistence</groupId>
<artifactId>eclipselink</artifactId>
<version>2.7.0</version>
</dependency>
I get the following error at runtime:
java.lang.SecurityException: class "javax.persistence.Cacheable"'s signer information does not match signer information of other classes in the same package
The javax.persistence-2.2.0 artifact is signed and contains the javax.persistence.Cacheable.class annotation, while the eclipselink-2.7.0 artifact is not signed and also contains the same java class annotation.
How can this be fixed?
Edit
Replacing the javax.persistence artifact version 2.2.0 by the version 2.1.1 fixes the problem (this one is not signed), but I'm not sure it's a normal situation.
Thanks Stéphane - the edit at the end of your question helped me "fix" the same problem. For anyone else who hits this as well - here is an expanded answer. This is what you need to "fix" things in your pom (until Eclipse fix things properly):
<!-- See https://stackoverflow.com/q/45870753 -->
<dependency>
<groupId>org.eclipse.persistence</groupId>
<artifactId>eclipselink</artifactId>
<version>2.7.0</version>
<exclusions>
<exclusion>
<groupId>org.eclipse.persistence</groupId>
<artifactId>javax.persistence</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.eclipse.persistence</groupId>
<artifactId>javax.persistence</artifactId>
<version>2.1.1</version>
</dependency>
This pulls in eclipselink but excludes the javax.persistence dependency that it tries to pull in and replaces it with an earlier version of javax.persistence that doesn't have the signing issue.
Aside: javax.persistence version 2.2.0 is explicitly pulled in, in the pom fragment shown in the original question, despite already being a transitive dependency of eclipselink.
Explanation
Summary - the eclipselink artifact depends on javax.persistence and both contain classes that are in the package javax.persistence. However the javax.persistence jar is signed while the eclipselink one is not. So the Java runtime will complain, when loading a class from the package javax.persistence in the eclipselink jar, that it's lack of signing doesn't match with classes already loaded from the same package in the javax.persistence jar.
Details - if I put a breakpoint in java.util.concurrent.ConcurrentHashMap.putIfAbsent(K, V) with condition "javax.persistence".equals(arg0) then I see that javax.persistence is mapped to the following CodeSource value:
(file:/Users/georgehawkins/.m2/repository/org/eclipse/persistence/javax.persistence/2.2.0/javax.persistence-2.2.0.jar [
[
Version: V3
Subject: CN="Eclipse Foundation, Inc.", OU=IT, O="Eclipse Foundation, Inc.", L=Ottawa, ST=Ontario, C=CA
Signature Algorithm: SHA256withRSA, OID = 1.2.840.113549.1.1.11
...
I.e. javax.persistence-2.2.0.jar is signed by the Eclipse Foundation and contains classes in the package javax.persistence. This jar is pulled in when some part of my application (actually something deep in Spring logic) tries to load javax.persistence.EntityManagerFactory.
If I then put a breakpoint in java.lang.ClassLoader.checkCerts(String, CodeSource) on the throw new SecurityException line I then see that it hits this line when the passed in CodeSource is:
(file:/Users/georgehawkins/.m2/repository/org/eclipse/persistence/eclipselink/2.7.0/eclipselink-2.7.0.jar <no signer certificates>)
I.e. eclipselink-2.7.0.jar also contain classes that are in the javax.persistence package but it is unsigned so a clash occurs that results in a SecurityException being thrown. This happens when something (also deep in Spring logic) tries to load javax.persistence.PersistenceUtil.
If I look at the output of mvn dependency:tree I see that this mismatch seems to be down to eclipselink itself - it is pulling in org.eclipse.persistence:javax.persistence:jar:2.2.0 itself. I.e. it isn't some clash with some other dependency:
[INFO] | \- org.eclipse.persistence:eclipselink:jar:2.7.0:compile
[INFO] | +- org.eclipse.persistence:javax.persistence:jar:2.2.0:compile
[INFO] | +- org.eclipse.persistence:commonj.sdo:jar:2.1.1:compile
[INFO] | +- javax.validation:validation-api:jar:1.1.0.Final:compile
[INFO] | \- org.glassfish:javax.json:jar:1.0.4:compile
I've logged this now at bugs.eclipse.org - see bug 525457.
To fix this issue, put in the correct JPA 2.2 compliant dependency for EclipseLink 2.7.x, in your maven pom file, as:
<dependency>
<groupId>org.eclipse.persistence</groupId>
<artifactId>org.eclipse.persistence.jpa</artifactId>
<version>2.7.1</version>
</dependency>
eclipselink.jar as such is designed as all-in-one bundle, not osgi enabled jar containing all partsof eclipselink project (ie sdo, oracle db specific stuff, dbws, nosql..) with ability to run with jpa api 2.0 on the classpath - at least in 2.x versions. In many cases this is not needed and proper components can be used instead, such as org.eclipse.persistence.jpa, org.eclipse.persistence.oracle etc. For the full list see ie: http://search.maven.org/#search%7Cga%7C1%7Corg.eclipse.persistence
This strange situation still seems to exist, in my case not using Maven, just trying to get a simple JPA example to run (and it is really frustrating if you need hours just to achieve that).
With 2.7.4 from January, this error occurs if you put the eclipselink.jar and jakarta.persistence_2.2.2.jar from the zip on the classpath.
In the end solution was to change order on the classpath: first the jakarta-persistence and only after that the eclipselink-jar.
So all javax.persistence classes are taken from jakarta-jar and not partly of the eclipselink-jar (if included there).
So I really wonder various things.
The eclipselink package should be all-in-one? But it is not. Some javax.persistence classes are contained. Others not - basic classes to be used in JPA code like EntityManager. Of course, together with the jakarta-jar included in the zip it is complete - but you may not use the two jars together with the "wrong" order on the classpath!? I really consider this a bug - or at least there should be a HUGE hint about this in the package then.
What is the org.eclipse.persistence.jpa-2.7.4.jar from Maven that is suggested here? It does not have the problems of the eclipselink.jar yes, not this error message. But then it also just seems not to include the Eclipselink JPA implementation, at least running with it I got error that persistence-unit referenced in code does not exist (same persistence.xml working with eclipselink.jar).
Strange situation.
My project was working on JDK-8, but stopped to work when I upgraded it to openJDK-11.
I solved it excluding the jpa-persistence module, and adding again on the version 2.2:
dependencies.create('org.eclipse.persistence:eclipselink:2.7.4') {
exclude module: "javax.persistence"
},
'javax.persistence:javax.persistence-api:2.2', //add it again, manually
'org.eclipse.persistence:org.eclipse.persistence.asm:2.7.4',
'org.eclipse.persistence:org.eclipse.persistence.antlr:2.7.4',
'org.eclipse.persistence:org.eclipse.persistence.moxy:2.7.4',
'org.eclipse.persistence:org.eclipse.persistence.core:2.7.4'
I fixed this by switching the order in which the jars appear in the classpath. In my case, I'm using Tomcat and had to modify catalina.properties to put javax before eclipselink.
Obinna's answer is correct; I guess that there was an issue with eclipselink 2.7.x –as George indicated. I had a similar issue when upgrading eclipselink, but it was just wrong artefacts. The initially described issue seems to be a result of externally referencing javax.persistence level - it is definitely not necessary.
Proper maven configuration can be found in eclipselink wiki:
https://wiki.eclipse.org/EclipseLink/Maven
I also run into this problem, with my case being a bit different, in that I am not using Maven. However, I place an answer here, as it might give people an idea about how to deal with this in their own situation. After all, the title is about this mismatch, in general, one sub-case being when using Maven.
I am using eclipselink in a NetBeans project. Initially, I was placing both the the eclipselink jar file (eclipselink-2.7.0.jar) and the needed org.eclipse.persistence jar files as external libraries to my project. Comments by Sergey and entreprenr above are what actually lead me to solve my problem. What I had to do was create a new library (Tools->Libraries->New Library...) which does not contain the eclipselink jar file (i.e. eclipselink-2.7.0.jar is not added in the library), only the specific org.eclipse.persistence jar files that are necessary for the project, e.g. org.eclipse.persistence.antlr-2.7.0.jar, org.eclipse.persistence.asm-2.7.0.jar, org.eclipse.persistence.core-2.7.0.jar, org.eclipse.persistence.jpa.modelgen.processor-2.7.0.jar, org.eclipse.persistence.jpa-2.7.0.jar, etc. I then added this library to my project and the exception vanished.
Of course, I also had to replace all org.eclipse.persistence jar files on my server with their 2.7.0 version and also replace the javax.persistence.jar with its 2.2.0 version (I use payara, so these are located under <payara_home>\glassfish\modules).
I'm using gradle in my project build and to solve the OP's problem, which I had as well, I finally used the following working setup.
dependencies {
testImplementation(group: 'org.eclipse.persistence', name: 'eclipselink', version: '2.7.4') {
exclude group: 'javax.validation', module: 'validation-api'
exclude group: 'org.eclipse.persistence', module: 'javax.persistence'
exclude group: 'org.eclipse.persistence', module: 'commonj.sdo'
exclude group: 'org.eclipse.persistence', module: 'jakarta.persistence'
}
testImplementation(group: 'org.eclipse.persistence', name: 'org.eclipse.persistence.jpa', version: '2.7.4') {
exclude group: 'org.eclipse.persistence', module: 'jakarta.persistence'
}
}
Instead of "testImplementation" you can of course use any dependency type you want or need.
After reading Sergey's comment I've improved this by just using:
dependencies {
testImplementation group: 'org.eclipse.persistence', name: 'org.eclipse.persistence.jpa', version: '2.7.4'
}
I think the last one is the best solution.
Because I could not find an answer for this problem when only using a Tomcat and this thread is often linked with this problem, I am going to post my solution here:
Since the signature is in the MANIFEST.MF you can change the signatures in the .jar files using 7zip or WinRAR to open them or simply delete them from the META-INF files of both .jar's and then import the changed files to your IDE.
A useful thread for the Signature-Mismatch-Problem is this thread: Java SecurityException: signer information does not match
Summary
When trying XMLConfiguration configuration = new XMLConfiguration("config/config.xml"); with only commons-configuration 1.10 I need to add more depencies (namely commons-collections not newer than 3.2.1) to my maven setup. Why is that so and why doesn't maven simply resolve all needed dependencies?
Details
I am trying to get commons-configuration to work. First I wanted to use the latest version, 2.0-alpha2, which didn't work well at all since I was unable to configure Maven to download the correct ressources - but that is another story.
After I found out that version 1.10 is in fact "one point ten" (not "one point one zero") and thus the latest version of commons-configuration 1 (and covered by the tutorials), I decided to give it a try instead.
For my maven dependencies (integrated in eclipse) I used:
<dependency>
<groupId>commons-configuration</groupId>
<artifactId>commons-configuration</artifactId>
<version>1.10</version>
</dependency>
However, when trying out this example:
package main;
import java.util.Iterator;
import org.apache.commons.configuration.ConfigurationException;
import org.apache.commons.configuration.XMLConfiguration;
public class ConfigurationTest {
public static void main(String... args) {
try {
XMLConfiguration configuration =
new XMLConfiguration("config/config.xml");
Iterator<String> iterator = configuration.getKeys();
while (iterator.hasNext()) {
System.out.println(iterator.next());
}
} catch (ConfigurationException e) {
e.printStackTrace();
}
}
}
with the following config.xml:
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<configuration>
<property>value</property>
<nestedproperty>
<arrayvalue>0,1,2,3,4</arrayvalue>
<property>anothervalue</property>
</nestedproperty>
</configuration>
I got the error:
Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/commons/collections/CollectionUtils
at org.apache.commons.configuration.XMLConfiguration.constructHierarchy(XMLConfiguration.java:640)
at org.apache.commons.configuration.XMLConfiguration.initProperties(XMLConfiguration.java:596)
at org.apache.commons.configuration.XMLConfiguration.load(XMLConfiguration.java:1009)
at org.apache.commons.configuration.XMLConfiguration.load(XMLConfiguration.java:972)
at org.apache.commons.configuration.XMLConfiguration$XMLFileConfigurationDelegate.load(XMLConfiguration.java:1647)
at org.apache.commons.configuration.AbstractFileConfiguration.load(AbstractFileConfiguration.java:324)
at org.apache.commons.configuration.AbstractFileConfiguration.load(AbstractFileConfiguration.java:261)
at org.apache.commons.configuration.AbstractFileConfiguration.load(AbstractFileConfiguration.java:238)
at org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.load(AbstractHierarchicalFileConfiguration.java:184)
at org.apache.commons.configuration.AbstractHierarchicalFileConfiguration.<init>(AbstractHierarchicalFileConfiguration.java:95)
at org.apache.commons.configuration.XMLConfiguration.<init>(XMLConfiguration.java:261)
at main.ConfigurationTest.main(ConfigurationTest.java:12)
I first hoped they (not me, of course) just screwed up some maven dependencies and since I wouldn't bother which version to use anyway anymore (I didn't get 2.0 to work, remember?) I decided to go down to version 1.9 by replacing the maven dependency with:
<dependency>
<groupId>commons-configuration</groupId>
<artifactId>commons-configuration</artifactId>
<version>1.9</version>
</dependency>
That solved the problem pretty well, the test case is running:
property
nestedproperty.arrayvalue
nestedproperty.property
But when I tried to implement a similar example to the one referenced in Very simple Apache-commons configuration example throws NoClassDefFoundError and its follow-up question I got the exact same error which is referenced there - but the solution, importing org.apache.commons.beanutils.PropertyUtils is not working as I am missing the beanutils. So basically by downgrading I just switched from the error of missing the collections to missing beanutils.
There is a dependency overview where you can see which dependencies are used when you do what. I was a bit suprised to learn that version 1.10 now used other dependencies (namely the CollectionUtils) than 1.9 did in the constructor call. Since there were dependency problems in 1.10 as well as in 1.9 I just sticked to the newer version.
I found the CollectionUtils located in the following artifact (as I was pointed there by its maven repository):
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-collections4</artifactId>
<version>4.0</version>
</dependency>
Sadly that one (not obvious to me at first) doesn't define the class CollectionUtils in the package collections, but in the package collections4. It was hinted at this problem on the dependency overview, but they only mentioned possible problems with earlier versions... I appeared to be at a point of not thinking much about it anymore but simply changed the dependency to:
<dependency>
<groupId>commons-collections</groupId>
<artifactId>commons-collections</artifactId>
<version>3.2.1</version>
</dependency>
I got everything to work (more or less, but the Exceptions I get now are not anymore depending on missing class definitions) after using these dependencies:
<dependencies>
<dependency>
<groupId>commons-configuration</groupId>
<artifactId>commons-configuration</artifactId>
<version>1.10</version>
</dependency>
<dependency>
<groupId>commons-collections</groupId>
<artifactId>commons-collections</artifactId>
<version>3.2.1</version>
</dependency>
<dependency>
<groupId>commons-beanutils</groupId>
<artifactId>commons-beanutils</artifactId>
<version>1.9.2</version>
</dependency>
</dependencies>
Why do I have to add the dependencies myself? I thought the whole point in using maven is to avoid having to do such things and in terms of javadocs and source files it does a pretty good job.
By now I am convinced that the dependencies are not included in the hierarchy by design (is that so?), probably to avoid overhead. However is there a way to either simply get all dependencies at once or even better to get all dependencies I need? And why is it designed this way?
If we analyse commons-configuration's POM we see that the commons-collections dependency is optional:
<dependencies>
<dependency>
<groupId>commons-collections</groupId>
<artifactId>commons-collections</artifactId>
<version>3.2.1</version>
<optional>true</optional>
</dependency>
...
Furthermore, from the Maven docs:
If a user wants to use functionality related to an optional
dependency, they will have to redeclare that optional dependency in
their own project.
This issue is explained on the Runtime dependencies page of the Commons Configuration website.
Quoting from that page:
A lot of dependencies are declared in the Maven POM. These are all needed during compile time. On runtime however you only need to add the dependencies to your classpath that are required by the parts of the Commons Configuration package you are using. The following table helps you to determine which dependencies you have to include based on the components you intend to use.
The other answers explain why this works from a Maven perspective. This answer is intended to provide a defence, of sorts, to the Commons Configuration folks. They did at least warn you!
In cases where the dependencies are on other Apache Commons components, they've taken the time to test with a variety of versions and have posted information on compatibility at the bottom of that page.
Maven tries to resolve all necessary dependencies for a library you're using in your pom. Well sometimes you have some dependencies which are only necessary for some specific features and you don't want to force the user of your dependency to download it if he doesn't use it. Then you're declaring your dependency as optional. This happened with commons-collections within commons-configuration. See commons-configuration-pom here
Above exception has been throwing While creating a hibernate session factory.
In application lib folder have hibernate-jpa-2.1-api and javax.persistence.2.1.0. I can able to see the NamedStoredProcedureQuery class in both jar. But I am getting runtime error for classnotfoundexception. Any suggestion?
NamedStoredProcedureQuery class is available in hibernate-jpa-2.1-api jar. But this jar refers some other jar in run time. So I didn't get error in compile time and getting exception during runtime. I just added other hibernated libs through maven repository.Initially i used only hibernate-core. Now artifactIDs are hibernate-core,hibernate-validator,hibernate-commons-annotations,hibernate-jpa-2.0-api and hibernate-entitymanager.
I have a non-ideal solution. I ended up using hibernate-core 3 (3.6.10) which doesn't throw the same error.
I got this idea from Mario Schwaiger, CodeRanch, for a different, but similar, class not found exception: http://www.coderanch.com/t/509836/ORM/databases/Hibernate-java-lang-ClassNotFoundException-javax
Details: I'm doing something slightly different - integrating Hibernate 4 with Struts 1 (instead of Spring), but ran into the same NamedStoredProcedureQuery class not found problem. Adding hibernate-validator threw different errors. Other things that did not work for me were: adding hibernate-entitymanager, adding javax.persistence, and changing tomcat or eclipse java versions between Java 8 and 7.
You'll need to instantiate the sessionfactory differently between Hibernate 3 and 4.
Hopefully somebody will post a better solution to your Spring problem.
You have to add hibernate-entitymanager to your classpath.
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-entitymanager</artifactId>
<version>${hibernate.version}</version>
</dependency>