Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Virgo » Initial artifact vs plan deployed in pickup
Initial artifact vs plan deployed in pickup [message #1002421] Fri, 18 January 2013 09:46 Go to next message
Lorie Pisicchio is currently offline 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 10: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 09:39 Go to previous messageGo to next message
C TRAN-XUAN is currently offline 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.
Re: Initial artifact vs plan deployed in pickup [message #1006556 is a reply to message #1004076] Thu, 31 January 2013 12:26 Go to previous messageGo to next message
Glyn Normington is currently offline 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.
Re: Initial artifact vs plan deployed in pickup [message #1007105 is a reply to message #1006556] Mon, 04 February 2013 08:29 Go to previous messageGo to next message
C TRAN-XUAN is currently offline 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 ).

Thanks again!
Re: Initial artifact vs plan deployed in pickup [message #1007110 is a reply to message #1007105] Mon, 04 February 2013 08:48 Go to previous message
Glyn Normington is currently offline Glyn Normington
Messages: 1222
Registered: July 2009
Senior Member
Thanks for feeding back and all the best with your project.
Previous Topic:Optional import of a hibernate's package unexpectedly became unresolved
Next Topic:Configurations and service.factoryPid
Goto Forum:
  


Current Time: Sat Aug 23 13:24:42 EDT 2014

Powered by FUDForum. Page generated in 0.01702 seconds