Skip to main content


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 #543187] Mon, 28 June 2010 16:10 Go to next message
Assen Sotirov is currently offline Assen SotirovFriend
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 Go to previous messageGo to next message
Glyn Normington is currently offline Glyn NormingtonFriend
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 Go to previous messageGo to next message
Assen Sotirov is currently offline Assen SotirovFriend
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 Go to previous messageGo to next message
Glyn Normington is currently offline Glyn NormingtonFriend
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 Go to previous messageGo to next message
Assen Sotirov is currently offline Assen SotirovFriend
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 Go to previous messageGo to next message
Glyn Normington is currently offline Glyn NormingtonFriend
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 Go to previous messageGo to next message
Assen Sotirov is currently offline Assen SotirovFriend
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 #584594 is a reply to message #543584] Wed, 30 June 2010 07:30 Go to previous messageGo to next message
Glyn Normington is currently offline Glyn NormingtonFriend
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

Re: Class loader exception during JPA processing [message #641240 is a reply to message #584594] Wed, 24 November 2010 15:49 Go to previous message
Glyn Normington is currently offline Glyn NormingtonFriend
Messages: 1222
Registered: July 2009
Senior Member
This came up again and with a bit of careful observation by Dmitry Sklyut, is now fixed. See bug 330924.

Report message to a moderator

Previous Topic:Running Virgo in Eclipse
Next Topic:Try to use osgi compendium services
Goto Forum:
  

[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Mon Jan 20 00:20:22 GMT 2025

Powered by FUDForum. Page generated in 0.04473 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top

Sign up to our Newsletter

A fresh new issue delivered monthly