Skip to main content


Eclipse Community Forums

      Home
Home » Eclipse Projects » Virgo » Class loader exception during JPA processing
Class loader exception during JPA processing [message #543187] Mon, 28 June 2010 12:10 Go to next message
Eclipse UserFriend
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
Re: Class loader exception during JPA processing [message #543370 is a reply to message #543187] Tue, 29 June 2010 04:56 Go to previous messageGo to next message
Eclipse UserFriend
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 #543512 is a reply to message #543370] Tue, 29 June 2010 12:08 Go to previous messageGo to next message
Eclipse UserFriend
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.
Re: Class loader exception during JPA processing [message #543527 is a reply to message #543512] Tue, 29 June 2010 12:57 Go to previous messageGo to next message
Eclipse UserFriend
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.
Re: Class loader exception during JPA processing [message #543584 is a reply to message #543527] Tue, 29 June 2010 17:32 Go to previous messageGo to next message
Eclipse UserFriend
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.
Re: Class loader exception during JPA processing [message #543645 is a reply to message #543584] Wed, 30 June 2010 03:30 Go to previous messageGo to next message
Eclipse UserFriend
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.
Re: Class loader exception during JPA processing [message #584580 is a reply to message #543527] Tue, 29 June 2010 17:32 Go to previous messageGo to next message
Eclipse UserFriend
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.
Re: Class loader exception during JPA processing [message #584594 is a reply to message #543584] Wed, 30 June 2010 03:30 Go to previous messageGo to next message
Eclipse UserFriend
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.
Re: Class loader exception during JPA processing [message #641240 is a reply to message #584594] Wed, 24 November 2010 10:49 Go to previous message
Eclipse UserFriend
This came up again and with a bit of careful observation by Dmitry Sklyut, is now fixed. See bug 330924.
Previous Topic:Running Virgo in Eclipse
Next Topic:Try to use osgi compendium services
Goto Forum:
  


Current Time: Sun Jul 13 23:36:34 EDT 2025

Powered by FUDForum. Page generated in 0.57790 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