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 #543187]

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.EntityManagerSetupException: 
Exception Description: Predeployment of PersistenceUnit [app] failed.
Internal Exception: org.eclipse.virgo.kernel.osgi.framework.BundleClassLoaderUnavailableException: Failed to get class loader for bundle 'org.eclipse.virgo.region.user_0.0.0 [1]' - possible resolution problem.
	at org.eclipse.persistence.exceptions.EntityManagerSetupException.predeployFailed(EntityManagerSetupException.java:210)
	... 23 common frames omitted
Caused by: org.eclipse.virgo.kernel.osgi.framework.BundleClassLoaderUnavailableException: 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.EquinoxUtils.getBundleClassLoader(EquinoxUtils.java:69)
	at org.eclipse.virgo.kernel.userregion.internal.equinox.KernelBundleClassLoader.getBundleClassLoader(KernelBundleClassLoader.java:125)
	at org.eclipse.virgo.kernel.userregion.internal.equinox.KernelBundleClassLoader.access$4(KernelBundleClassLoader.java:124)
	at org.eclipse.virgo.kernel.userregion.internal.equinox.KernelBundleClassLoader$ThrowAwayClassLoader.findClassFromImport(KernelBundleClassLoader.java:415)
	at org.eclipse.virgo.kernel.userregion.internal.equinox.KernelBundleClassLoader$ThrowAwayClassLoader.findClassInternal(KernelBundleClassLoader.java:392)
	at org.eclipse.virgo.kernel.userregion.internal.equinox.KernelBundleClassLoader$ThrowAwayClassLoader.loadClass(KernelBundleClassLoader.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.PrivilegedAccessHelper.getClassForName(PrivilegedAccessHelper.java:88)
	at org.eclipse.persistence.internal.jpa.metadata.MetadataHelper.getClassForName(MetadataHelper.java:97)
	at org.eclipse.persistence.internal.jpa.metadata.ORMetadata.getJavaClass(ORMetadata.java:176)
	at org.eclipse.persistence.internal.jpa.metadata.ORMetadata.getJavaClass(ORMetadata.java:151)
	at org.eclipse.persistence.internal.jpa.metadata.converters.EnumeratedMetadata.process(EnumeratedMetadata.java:100)
	at org.eclipse.persistence.internal.jpa.metadata.accessors.mappings.MappingAccessor.processEnumerated(MappingAccessor.java:1340)
	at org.eclipse.persistence.internal.jpa.metadata.accessors.mappings.BasicAccessor.processEnumerated(BasicAccessor.java:340)
	at org.eclipse.persistence.internal.jpa.metadata.accessors.mappings.MappingAccessor.processJPAConverters(MappingAccessor.java:1354)
	at org.eclipse.persistence.internal.jpa.metadata.accessors.mappings.MappingAccessor.processMappingConverter(MappingAccessor.java:1422)
	at org.eclipse.persistence.internal.jpa.metadata.accessors.mappings.MappingAccessor.processMappingValueConverter(MappingAccessor.java:1440)
	at org.eclipse.persistence.internal.jpa.metadata.accessors.mappings.BasicAccessor.process(BasicAccessor.java:300)
	at org.eclipse.persistence.internal.jpa.metadata.accessors.mappings.IdAccessor.process(IdAccessor.java:69)
	at org.eclipse.persistence.internal.jpa.metadata.MetadataDescriptor.processAccessors(MetadataDescriptor.java:1287)
	at org.eclipse.persistence.internal.jpa.metadata.accessors.classes.ClassAccessor.processAccessors(ClassAccessor.java:825)
	at org.eclipse.persistence.internal.jpa.metadata.accessors.classes.EntityAccessor.processAccessors(EntityAccessor.java:847)
	at org.eclipse.persistence.internal.jpa.metadata.accessors.classes.EntityAccessor.process(EntityAccessor.java:708)
	at org.eclipse.persistence.internal.jpa.metadata.MetadataProject.processStage2(MetadataProject.java:1333)
	at org.eclipse.persistence.internal.jpa.metadata.MetadataProcessor.processORMMetadata(MetadataProcessor.java:461)
	at org.eclipse.persistence.internal.jpa.deployment.PersistenceUnitProcessor.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.EquinoxUtils.getBundleClassLoader(EquinoxUtils.java:67)
	... 50 common frames omitted

From the EclipseLink source:

org.eclipse.persistence.internal.security.PrivilegedAccessHelper(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 #543370 is a reply to message #543187]

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 #543512 is a reply to message #543370]

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.EquinoxUtils

class file.

Report message to a moderator

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

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

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

Tue, 29 June 2010 21:32

Assen Sotirov

Messages: 6
Registered: July 2009

Junior Member

I did replace the Spring 3.0.0.RELEASE in repository/ext with 3.0.2.RELEASE and removed the 3.0.2.RELEASE from repository/usr. Unfortunately I still see the exception.

I think that the real issue is why sometimes it works and sometimes not.

Report message to a moderator

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

Wed, 30 June 2010 07:30

Glyn Normington

Messages: 1222
Registered: July 2009

Senior Member

Ok - thanks for checking that.

I suggest it is worth getting to the bottom of the "Failed to get class loader for bundle 'org.eclipse.virgo.region.user_0.0.0 [1]' - possible resolution problem" first.

Let's assume for the moment that the bundle failed to resolve.

Since the server apparently comes up in this state, I suggest you use the Equinox console to investigate why that bundle does not resolve. The only tricky thing is that this bundle is a "surrogate" bundle which represents the kernel region in the user region. So its failure to resolve is probably related to the content of the kernel region.

See the diagnostics page on the wiki for details of how to use the Equinox console in kernel and user regions. The "diag" command is probably a good starting point.

Report message to a moderator

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

Tue, 29 June 2010 21:32

Assen Sotirov

Messages: 6
Registered: July 2009

Junior Member

Report message to a moderator

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

Wed, 30 June 2010 07:30

Glyn Normington

Messages: 1222
Registered: July 2009

Senior Member

Ok - thanks for checking that.

I suggest it is worth getting to the bottom of the "Failed to get class loader for bundle 'org.eclipse.virgo.region.user_0.0.0 [1]' - possible resolution problem" first.

Let's assume for the moment that the bundle failed to resolve.

Since the server apparently comes up in this state, I suggest you use the Equinox console to investigate why that bundle does not resolve. The only tricky thing is that this bundle is a "surrogate" bundle which represents the kernel region in the user region. So its failure to resolve is probably related to the content of the kernel region.

See the http://wiki.eclipse.org/Virgo/Diagnostics page on the wiki for details of how to use the Equinox console in kernel and user regions. The "diag" command is probably a good starting point.

Report message to a moderator