Eclipse Community Forums: Virgo » Class loader exception during JPA processing

Help

Home

Home » Eclipse Projects » Virgo » Class loader exception during JPA processing

Show: Today's Messages :: Show Polls :: Message Navigator

Class loader exception during JPA processing [message #584518]

Mon, 28 June 2010 16:10

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

Report message to a moderator

Re: Class loader exception during JPA processing [message #584546 is a reply to message #584518]

Tue, 29 June 2010 08:56

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?

Report message to a moderator

Re: Class loader exception during JPA processing [message #584562 is a reply to message #584546]

Tue, 29 June 2010 16:08

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.

Report message to a moderator

Re: Class loader exception during JPA processing [message #584569 is a reply to message #584562]

Tue, 29 June 2010 16:57

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.

Report message to a moderator

Previous Topic:	Split persistent model in mulptiple bundles?
Next Topic:	Renamed download files

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Fri Apr 19 05:01:03 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter