After further review, using Glassfish 2.1.1 I received this error message in the server log:
Caused by: java.lang.LinkageError: loader constraint violation: when resolving method "org.apache.openjpa.persistence.validation.ValidationUtils.setupValidation(Lorg/apache/openjpa/conf/OpenJPAConfiguration;)Z" the class loader (instance of org/apache/catalina/loader/WebappClassLoader) of the current class, org/apache/openjpa/persistence/PersistenceProviderImpl, and the class loader (instance of sun/misc/Launcher$AppClassLoader) for resolved class, org/apache/openjpa/persistence/validation/ValidationUtils, have different Class objects for the type org/apache/openjpa/conf/OpenJPAConfiguration used in the signature So it appears to be the WebappClassLoader and the AppClassLoader are both loading the OpenJPAConfiguration from the same JAR file, causing the error when the class is trying to be resolved in this particular method.. seth.jackson wrote: > > It appears something was modified in OpenJPA 2.0 M3 from M2 that causes a > LinkageError. > > In my current environment, I've tested both Glassfish and Tomcat using M2 > and M3. M2 runs without problems, but M3 throws a linkage error as > follows: > > Caused by: java.lang.LinkageError: loader constraint violation: loader > (instance of sun/misc/Launcher$AppClassLoader) previously initiated > loading for a different type with name > "org/apache/openjpa/conf/OpenJPAConfiguration" > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:621) > at > java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) > at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) > at java.net.URLClassLoader.access$000(URLClassLoader.java:56) > at java.net.URLClassLoader$1.run(URLClassLoader.java:195) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > at java.lang.ClassLoader.loadClass(ClassLoader.java:307) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) > at java.lang.ClassLoader.loadClass(ClassLoader.java:252) > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320) > at > org.apache.openjpa.persistence.validation.ValidationUtils.setupValidation(ValidationUtils.java:53) > at > org.apache.openjpa.persistence.PersistenceProviderImpl.loadValidator(PersistenceProviderImpl.java:290) > at > org.apache.openjpa.persistence.PersistenceProviderImpl.createEntityManagerFactory(PersistenceProviderImpl.java:97) > at > org.apache.openjpa.persistence.OpenJPAPersistence.createEntityManagerFactory(OpenJPAPersistence.java:128) > at > org.apache.openjpa.persistence.OpenJPAPersistence.createEntityManagerFactory(OpenJPAPersistence.java:111) > at test_test.user.UserAction.execute(UserAction.java:39) > > > I've already confirmed that the OpenJPA classes in question do NOT exist > in any other JARs in the path. > > ValidationUtils.setupValidation(ValidationUtils.java:53) calls the > OpenJPAConfiguration.getConfigurationLog(). The object being referenced is > JDBCConfigurationImpl, which in other classes retrieves the log reference > perfectly fine, before it gets to the offending line. > -- View this message in context: http://n2.nabble.com/Struts-2x-OpenJPA-2-0-M3-Tomcat-or-Glassfish-tp4087312p4093228.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
