Eclipse Community Forums: Virgo » Initial artifact vs plan deployed in pickup

Help

Home

Home » Eclipse Projects » Virgo » Initial artifact vs plan deployed in pickup

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

Initial artifact vs plan deployed in pickup [message #1002421]

Fri, 18 January 2013 14:46

Lorie Pisicchio

Messages: 44
Registered: October 2010

Member

Hi all,
I am observing a behavior I have never seen before.
We are building a platform on top of Virgo 3.5. The platform is composed of a set of bundles, organized in plans. To make sure that the platform is ready when our users deploy their application (by placing their bundles in pickup), we are starting our platform plans into initialArtifacts (by editing user region properties file).
We are using JPA for automatic generation of persistence entities.
One of my plans won't deploy when started in initialArtifacts. It fails with the following error.

[2013-01-18 15:37:23.536] region-dm-1                  <AG0000E> Application context creation failure for bundle 'my-bundle' version '3.1.0.BUILD-SNAPSHOT'. org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'sendingTask' defined in URL [bundleentry://231.fwk1587097459/META-INF/spring/context.xml]: Cannot resolve reference to bean 'campaignService' while setting constructor argument; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'campaignService' defined in URL [bundleentry://231.fwk1587097459/META-INF/spring/context.xml]: Cannot resolve reference to bean 'campaignRepository' while setting bean property 'repository'; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'campaignRepository': FactoryBean threw exception on object creation; nested exception is java.lang.IllegalArgumentException: interface com.anything.MyInterface is not visible from class loader
	at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveReference(BeanDefinitionValueResolver.java:329)
	at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:107)
	at org.springframework.beans.factory.support.ConstructorResolver.resolveConstructorArguments(ConstructorResolver.java:630)
	at org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:148)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireConstructor(AbstractAutowireCapableBeanFactory.java:1035)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:939)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:485)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456)
	at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:294)
	at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:225)
	at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:291)
	at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193)
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:605)
	at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:925)
	at org.eclipse.gemini.blueprint.context.support.AbstractDelegatedExecutionApplicationContext.access$1600(AbstractDelegatedExecutionApplicationContext.java:60)
	at org.eclipse.gemini.blueprint.context.support.AbstractDelegatedExecutionApplicationContext$4.run(AbstractDelegatedExecutionApplicationContext.java:325)
	at org.eclipse.gemini.blueprint.util.internal.PrivilegedUtils.executeWithCustomTCCL(PrivilegedUtils.java:85)
	at org.eclipse.gemini.blueprint.context.support.AbstractDelegatedExecutionApplicationContext.completeRefresh(AbstractDelegatedExecutionApplicationContext.java:290)
	at org.eclipse.gemini.blueprint.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor$CompleteRefreshTask.run(DependencyWaiterApplicationContextExecutor.java:137)
	at org.eclipse.virgo.kernel.agent.dm.ContextPropagatingTaskExecutor$2.run(ContextPropagatingTaskExecutor.java:95)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
	at java.lang.Thread.run(Thread.java:722)
Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'campaignService' defined in URL [bundleentry://231.fwk1587097459/META-INF/spring/context.xml]: Cannot resolve reference to bean 'campaignRepository' while setting bean property 'repository'; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'campaignRepository': FactoryBean threw exception on object creation; nested exception is java.lang.IllegalArgumentException: interface com.anything.MyInterface is not visible from class loader
	at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveReference(BeanDefinitionValueResolver.java:329)
	at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:107)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:1360)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1118)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:517)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456)
	at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:294)
	at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:225)
	at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:291)
	at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193)
	at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveReference(BeanDefinitionValueResolver.java:323)
	... 22 common frames omitted
Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'campaignRepository': FactoryBean threw exception on object creation; nested exception is java.lang.IllegalArgumentException: interface com.anything.MyInterface is not visible from class loader
	at org.springframework.beans.factory.support.FactoryBeanRegistrySupport.doGetObjectFromFactoryBean(FactoryBeanRegistrySupport.java:149)
	at org.springframework.beans.factory.support.FactoryBeanRegistrySupport.getObjectFromFactoryBean(FactoryBeanRegistrySupport.java:102)
	at org.springframework.beans.factory.support.AbstractBeanFactory.getObjectForBeanInstance(AbstractBeanFactory.java:1442)
	at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:248)
	at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193)
	at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveReference(BeanDefinitionValueResolver.java:323)
	... 32 common frames omitted
Caused by: java.lang.IllegalArgumentException: interface com.anything.MyInterface is not visible from class loader
	at java.lang.reflect.Proxy.getProxyClass(Proxy.java:373)
	at java.lang.reflect.Proxy.newProxyInstance(Proxy.java:601)
	at org.springframework.aop.framework.JdkDynamicAopProxy.getProxy(JdkDynamicAopProxy.java:117)
	at org.springframework.aop.framework.JdkDynamicAopProxy.getProxy(JdkDynamicAopProxy.java:108)
	at org.springframework.aop.framework.ProxyFactory.getProxy(ProxyFactory.java:98)
	at org.springframework.data.repository.core.support.RepositoryFactorySupport.getRepository(RepositoryFactorySupport.java:150)
	at org.springframework.data.repository.core.support.RepositoryFactoryBeanSupport.getObject(RepositoryFactoryBeanSupport.java:125)
	at org.springframework.data.repository.core.support.RepositoryFactoryBeanSupport.getObject(RepositoryFactoryBeanSupport.java:41)
	at org.springframework.beans.factory.support.FactoryBeanRegistrySupport.doGetObjectFromFactoryBean(FactoryBeanRegistrySupport.java:142)
	... 37 common frames omitted

com.anything package is declared in the bundle my-bundle (the one that fails to deploy because it cannot load the interface). This package is the base package for jpa repositories.

If I remove this plan from initialArtifacts, and deploy it into the pickup directory, then it will install correctly.

Someone could explain me what is the difference between the two exposed cases? In my understanding, initialArtifacts were bundles deployed in user region, just as bundles deployed into pickup. The only difference I'm aware of is that those bundles are deployed before any others.

Any help will be appreciated.
Thanx in advance.

[Updated on: Fri, 18 January 2013 15:28]

Report message to a moderator

Re: Initial artifact vs plan deployed in pickup [message #1004076 is a reply to message #1002421]

Tue, 22 January 2013 14:39

C TRAN-XUAN

Messages: 8
Registered: December 2011

Junior Member

To complete Lorie's comment...

We use:

- Virgo 3.5.0
- Spring Framework 3.1.3.RELEASE
- Spring Data MongoDB 1.1.1.RELEASE
- Spring Data JPA 1.2.0.RELEASE
- Gemini JPA 1.0.0.RELEASE
- EclipseLink 2.3.1

We have mainly 3 bundles:

- virgo-cl-mongo: declares an OSGi service "userService" based on a Spring Data MongoDB Repository
- virgo-cl-jpa: declares an OSGi service "personService" which imports the OSGi service "userService" and also use a Spring Data JPA Repository
- virgo-cl-client: imports/uses the OSGi service "personService". Used just to activate the two previous bundles.

A plan "myrepo.plan" starts these 3 bundles in the proper order and is deployed in a specific repository in $VIRGO_HOME/repository/myrepo/. To do that, we have modified both org.eclipse.virgo.kernel.userregion.properties and org.eclipse.virgo.repository.properties.

... and we get the following error:

[2013-01-22 14:54:45.101] region-dm-12                 <AG0000E> Application context creation failure for bundle 'org.foo.bar.virgo-cl-jpa' version '0.0.1.BUILD-SNAPSHOT'. org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.eclipse.gemini.blueprint.service.exporter.support.OsgiServiceFactoryBean#0': Invocation of init method failed; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'personService' defined in URL [bundleentry://140.fwk2046621584/META-INF/spring/context.xml]: Cannot resolve reference to bean 'personRepository' while setting bean property 'personRepository'; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'personRepository': FactoryBean threw exception on object creation; nested exception is java.lang.IllegalArgumentException: interface org.foo.bar.jpa.repository.PersonRepository is not visible from class loader
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1455)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:519)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456)
	at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:294)
	at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:225)
	at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:291)
	at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:193)
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:587)
	at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:925)
	at org.eclipse.gemini.blueprint.context.support.AbstractDelegatedExecutionApplicationContext.access$1600(AbstractDelegatedExecutionApplicationContext.java:60)
	at org.eclipse.gemini.blueprint.context.support.AbstractDelegatedExecutionApplicationContext$4.run(AbstractDelegatedExecutionApplicationContext.java:325)
	at org.eclipse.gemini.blueprint.util.internal.PrivilegedUtils.executeWithCustomTCCL(PrivilegedUtils.java:85)
	at org.eclipse.gemini.blueprint.context.support.AbstractDelegatedExecutionApplicationContext.completeRefresh(AbstractDelegatedExecutionApplicationContext.java:290)
	at org.eclipse.gemini.blueprint.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor$CompleteRefreshTask.run(DependencyWaiterApplicationContextExecutor.java:137)
	at org.eclipse.virgo.kernel.agent.dm.ContextPropagatingTaskExecutor$2.run(ContextPropagatingTaskExecutor.java:95)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:662)

After setting some breakpoints ("org.springframework.aop.framework.JdkDynamicAopProxy.getProxy() / org.springframework.util.ClassUtils.getDefaultClassLoader()"), it appears that the classloader used by the bundle "virgo-cl-jpa_0.0.1.BUILD-SNAPSHOT.jar" to load the bean 'personRepository' is actually the classloader of the bundle "virgo-cl-mongo_0.0.01.BUILD-SNAPSHOT". Hence the error...

The only thing we can notice is the fact that the bundle "virgo-cl-jpa_0.0.1.BUILD-SNAPSHOT.jar" imports services form "virgo-cl-mongo_0.0.01.BUILD-SNAPSHOT".

On the other hand, if we don't deploy "virgo-cl-jpa_0.0.1.BUILD-SNAPSHOT.jar" with the plan but deploy the bundle in the pickup, then the bundle is deployed successfully.

Any idea about the difference? Any help would be appreciated.
Thanks in advance.

PS: an archive code in attachment that has been tested with Virgo 3.6.0.RELEASE (to see whether the issue appears in this release too) that reproduces the issue. See README.txt of the archive.

Attachment: virgo-cl-parent.tar.gz
(Size: 30.00KB, Downloaded 246 times)

Report message to a moderator

Re: Initial artifact vs plan deployed in pickup [message #1006556 is a reply to message #1004076]

Thu, 31 January 2013 17:26

Glyn Normington

Messages: 1222
Registered: July 2009

Senior Member

I don't see why initialArtifacts would cause this problem other than the fact that pickup contents are deployed after all the initial artifacts, so this is probably some kind of timing problem. In such circumstances, I usually play spot the difference between the working and broken setups using a debugger (if the debugger doesn't mess up the timing). It seems like you are doing pretty well, having identified a class loading anomaly. The trick now is to chase this back to the root cause, which is presumably where the class loaders are set up. But it's hard to give more detailed advice than that I'm afraid.

Report message to a moderator

Re: Initial artifact vs plan deployed in pickup [message #1007105 is a reply to message #1006556]

Mon, 04 February 2013 13:29

C TRAN-XUAN

Messages: 8
Registered: December 2011

Junior Member

Thanks for the reply!
Right now, we have found a workaround which is separating the Spring Data repositories from the Service classes that use them, into 2 separate bundles. Doing that and using the initialArtifacts seems to fix the issue.
If we find the root cause, we'll get back to the forum (hopefully with a solution Smile