Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Virgo » Class loader exception during JPA processing
Class loader exception during JPA processing [message #584518] Mon, 28 June 2010 12:10 Go to next message
Assen Sotirov is currently offline Assen Sotirov
Messages: 6
Registered: July 2009
Junior Member
I am using EclipseLink 2.0.2 with Spring 3.0.2 and 60% of the time I am getting the following exception during the start of my bundle:


Caused by: org.eclipse.persistence.exceptions.EntityManagerSetupExcepti on:
Exception Description: Predeployment of PersistenceUnit [app] failed.
Internal Exception: org.eclipse.virgo.kernel.osgi.framework.BundleClassLoaderUna vailableException: Failed to get class loader for bundle 'org.eclipse.virgo.region.user_0.0.0 [1]' - possible resolution problem.
at org.eclipse.persistence.exceptions.EntityManagerSetupExcepti on.predeployFailed(EntityManagerSetupException.java:210)
... 23 common frames omitted
Caused by: org.eclipse.virgo.kernel.osgi.framework.BundleClassLoaderUna vailableException: Failed to get class loader for bundle 'org.eclipse.virgo.region.user_0.0.0 [1]' - possible resolution problem.
at org.eclipse.virgo.kernel.userregion.internal.equinox.Equinox Utils.getBundleClassLoader(EquinoxUtils.java:69)
at org.eclipse.virgo.kernel.userregion.internal.equinox.KernelB undleClassLoader.getBundleClassLoader(KernelBundleClassLoade r.java:125)
at org.eclipse.virgo.kernel.userregion.internal.equinox.KernelB undleClassLoader.access$4(KernelBundleClassLoader.java:124)
at org.eclipse.virgo.kernel.userregion.internal.equinox.KernelB undleClassLoader$ThrowAwayClassLoader.findClassFromImport(Ke rnelBundleClassLoader.java:415)
at org.eclipse.virgo.kernel.userregion.internal.equinox.KernelB undleClassLoader$ThrowAwayClassLoader.findClassInternal(Kern elBundleClassLoader.java:392)
at org.eclipse.virgo.kernel.userregion.internal.equinox.KernelB undleClassLoader$ThrowAwayClassLoader.loadClass(KernelBundle ClassLoader.java:364)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:247)
at org.eclipse.persistence.internal.security.PrivilegedAccessHe lper.getClassForName(PrivilegedAccessHelper.java:88)
at org.eclipse.persistence.internal.jpa.metadata.MetadataHelper .getClassForName(MetadataHelper.java:97)
at org.eclipse.persistence.internal.jpa.metadata.ORMetadata.get JavaClass(ORMetadata.java:176)
at org.eclipse.persistence.internal.jpa.metadata.ORMetadata.get JavaClass(ORMetadata.java:151)
at org.eclipse.persistence.internal.jpa.metadata.converters.Enu meratedMetadata.process(EnumeratedMetadata.java:100)
at org.eclipse.persistence.internal.jpa.metadata.accessors.mapp ings.MappingAccessor.processEnumerated(MappingAccessor.java: 1340)
at org.eclipse.persistence.internal.jpa.metadata.accessors.mapp ings.BasicAccessor.processEnumerated(BasicAccessor.java:340)
at org.eclipse.persistence.internal.jpa.metadata.accessors.mapp ings.MappingAccessor.processJPAConverters(MappingAccessor.ja va:1354)
at org.eclipse.persistence.internal.jpa.metadata.accessors.mapp ings.MappingAccessor.processMappingConverter(MappingAccessor .java:1422)
at org.eclipse.persistence.internal.jpa.metadata.accessors.mapp ings.MappingAccessor.processMappingValueConverter(MappingAcc essor.java:1440)
at org.eclipse.persistence.internal.jpa.metadata.accessors.mapp ings.BasicAccessor.process(BasicAccessor.java:300)
at org.eclipse.persistence.internal.jpa.metadata.accessors.mapp ings.IdAccessor.process(IdAccessor.java:69)
at org.eclipse.persistence.internal.jpa.metadata.MetadataDescri ptor.processAccessors(MetadataDescriptor.java:1287)
at org.eclipse.persistence.internal.jpa.metadata.accessors.clas ses.ClassAccessor.processAccessors(ClassAccessor.java:825)
at org.eclipse.persistence.internal.jpa.metadata.accessors.clas ses.EntityAccessor.processAccessors(EntityAccessor.java:847)
at org.eclipse.persistence.internal.jpa.metadata.accessors.clas ses.EntityAccessor.process(EntityAccessor.java:708)
at org.eclipse.persistence.internal.jpa.metadata.MetadataProjec t.processStage2(MetadataProject.java:1333)
at org.eclipse.persistence.internal.jpa.metadata.MetadataProces sor.processORMMetadata(MetadataProcessor.java:461)
at org.eclipse.persistence.internal.jpa.deployment.PersistenceU nitProcessor.processORMetadata(PersistenceUnitProcessor.java :390)
at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl. predeploy(EntityManagerSetupImpl.java:945)
... 22 common frames omitted
Caused by: java.lang.ClassCastException: org.eclipse.osgi.internal.composite.CompositeClassLoader cannot be cast to org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader
at org.eclipse.virgo.kernel.userregion.internal.equinox.Equinox Utils.getBundleClassLoader(EquinoxUtils.java:67)
... 50 common frames omitted


From the EclipseLink source:
org.eclipse.persistence.internal.security.PrivilegedAccessHe lper(88)
return Class.forName(className, initialize, loader);
org.eclipse.persistence.internal.jpa.metadata.MetadataHelper (97)
return PrivilegedAccessHelper.getClassForName(classname, true, loader);
org.eclipse.persistence.internal.jpa.metadata.ORMetadata(176 )
return MetadataHelper.getClassForName(convertedClassName, getMetadataFactory().getLoader());

It's always happens when processing enums. In my JPA annotated classes I am using:
@Enumerated(EnumType.STRING)

In the persistance.xml file the enums are not specified in the <class> tags.

I am starting Virgo Web server with:
-javaagent:path\spring-instrument-3.0.2.RELEASE.jar

It doesn't matter whether the bundle is specified in a plan or is a part of a par file.

The same is happening with the last version of DM server.

Thanks,
Assen
Re: Class loader exception during JPA processing [message #584546 is a reply to message #584518] Tue, 29 June 2010 04:56 Go to previous messageGo to next message
Glyn Normington is currently offline Glyn Normington
Messages: 1222
Registered: July 2009
Senior Member
The diagnostic which worries me most is "Failed to get class loader for bundle 'org.eclipse.virgo.region.user_0.0.0 [1]' - possible resolution problem". If the user region bundle cannot be resolved, that's going to have catastrophic effects later on and you may be simply observing some of these effects. In fact I'm surprised that Virgo comes up at all in those circumstances.

I think it is worth getting rid of that diagnostic before drilling down into any potential persistence issues.

You are probably aware that Virgo has two versions of Spring - one in the kernel region and the other in the user region. By default they are both at version 3.0.0.RELEASE. The design is that way so that users can upgrade Spring in the user region where applications reside by replacing Spring and the .libd file in repository/ext.

So I'm guessing that the javaagent is causing the problem as it is bringing an instrumented Spring 3.0.2 into the mix and, not only that, it is jamming Spring 3.0.2 into the boot strap class loader in a way which is most unsympathetic to OSGi class loading.

Can you reproduce the persistence problem without the javaagent?
Re: Class loader exception during JPA processing [message #584562 is a reply to message #584546] Tue, 29 June 2010 12:08 Go to previous messageGo to next message
Assen Sotirov is currently offline Assen Sotirov
Messages: 6
Registered: July 2009
Junior Member
Yes, it is reproducible - if I start the Virgo Web server without '-javaagent' I still see the same exception.

Also I am not replacing user region Spring version. The version of Spring that I am using - 3.0.2 is placed in repository/usr.

I am not sure why you are saying Quote:
> The diagnostic which worries me most is ...


It looks like an exception that happens in
org.eclipse.virgo.kernel.userregion.internal.equinox.Equinox Utils class file.
Re: Class loader exception during JPA processing [message #584569 is a reply to message #584562] Tue, 29 June 2010 12:57 Go to previous message
Glyn Normington is currently offline Glyn Normington
Messages: 1222
Registered: July 2009
Senior Member
To replace the version of Spring in the user region, you must replace the Spring bundles and .libd file in repository/ext and not place the new version of Spring in repository/usr.

Effectively, by placing the new version of Spring in repository/usr, there are two versions of Spring available in the repository chain and that is known to cause all sorts of problems.

Please could you make sure you replace Spring in repository/ext and clean start the server and try again.
Previous Topic:Split persistent model in mulptiple bundles?
Next Topic:Renamed download files
Goto Forum:
  


Current Time: Fri Aug 29 16:21:05 EDT 2014

Powered by FUDForum. Page generated in 0.01725 seconds