| Blueprint problem after moving from 3.5.0.M03 to 3.5.0.RELEASE or 3.6.0.M03 [message #978118] |
Fri, 09 November 2012 16:23  |
Eclipse User |
|
|
|
I'm getting a Blueprint post refresh exception after switching my application from 3.5.0.M03 to 3.5.0.RELEASE.
This is the stack trace:
[2012-11-09 15:27:01.686] region-dm-14 <AG0000E> Application context creation failure for bundle 'com.foo.batch' version '1.0.1.201211082348'. org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'decompose': Cannot resolve reference to bean 'jobRepository' while setting bean property 'jobRepository'; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'jobRepository': FactoryBean threw exception on object creation; nested exception is java.lang.IllegalArgumentException: interface org.springframework.batch.core.repository.JobRepository is not visible from class loader
at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveReference(BeanDefinitionValueResolver.java:328)
at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:106)
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.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:567)
at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:913)
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)
Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'jobRepository': FactoryBean threw exception on object creation; nested exception is java.lang.IllegalArgumentException: interface org.springframework.batch.core.repository.JobRepository 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:322)
... 20 common frames omitted
Caused by: java.lang.IllegalArgumentException: interface org.springframework.batch.core.repository.JobRepository is not visible from class loader
at java.lang.reflect.Proxy.getProxyClass(Proxy.java:353)
at java.lang.reflect.Proxy.newProxyInstance(Proxy.java:581)
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.batch.core.repository.support.AbstractJobRepositoryFactoryBean.getObject(AbstractJobRepositoryFactoryBean.java:198)
at org.springframework.beans.factory.support.FactoryBeanRegistrySupport.doGetObjectFromFactoryBean(FactoryBeanRegistrySupport.java:142)
... 25 common frames omitted
The bundle is in Active state and so is org.springframework.batch.core bundle. The org.springframework.batch.core.repository package is imported. I can successfully load org.springframework.batch.core.repository.JobRepository class into the bundle using clload. So it looks like a Blueprint is using the wrong class loader.
Switching Blueprint bundles to 1.0.2.RELEASE or deploying to Virgo 3.6.0.M03 produces the same results. I did switch Spring Framework to 3.1.1 in both versions.
This is a large application so it will be hard for me to provide a sample app.
Has anyone seen something similar? Any more ideas on how to troubleshoot this further?
Thanks,
Stan
|
|
|
|
|
|
| Re: Blueprint problem after moving from 3.5.0.M03 to 3.5.0.RELEASE or 3.6.0.M03 [message #982594 is a reply to message #982122] |
Tue, 13 November 2012 03:56  |
| Eclipse User |
|
|
|
It's hard to see how the presence or absence of the consumer bundle for the service exposed by the problematic bundle can have a functional effect on the building of the application context of the problematic bundle, so I guess it simply affects the resolution or the timing. The symptoms are consistent with an incorrect or missing package wiring. Since it sounds like your bundles are part of a plan, they are installed together and then resolved, so the ordering within the plan will affect resolution mainly because it will affect the order in which the bundles are installed. So I'm wondering if there is an oddity like multiple bundles exporting the same package (most likely org.springframework.batch.core.repository or a package in a uses relationship with that package) or a bundle containing a JAR containing the JobRepository interface.
I'd also like to confirm that you haven't edited the user region properties file as that could expose the kernel's instance of Gemini Blueprint or Spring framework to the user region inappropriately.
If these ideas don't give you any inspiration, then I'm afraid you'll need to debug the IllegalArgumentException in a debugger to find out which class loader(s) are being used. IllegalArgumentException is unusual, so you should be able to put a breakpoint on the exception being thrown. Bundle class loaders in Virgo have helpful toString methods so that you can easily tell which bundle they come from. When you're in the debugger, watching expressions like x.getClass().getClassLoader() is a good way to get to the defining class loader of a type of the variable x.
I'm keen to help you debug this, so let's keep in touch.
BTW moving to Nano would be a workaround rather than getting to the bottom of the problem, so I'm glad you don't want to go that way.
|
|
|
Powered by
FUDForum. Page generated in 0.07405 seconds
Home