Eclipse Community Forums: Virgo » Blueprint problem after moving from 3.5.0.M03 to 3.5.0.RELEASE or 3.6.0.M03

Home » Eclipse Projects » Virgo » Blueprint problem after moving from 3.5.0.M03 to 3.5.0.RELEASE or 3.6.0.M03

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 #981312 is a reply to message #978118]

Mon, 12 November 2012 05:18

Eclipse User

One way in would be to eye-ball the 50 odd bugs that were fixed between 3.5.0.M03 and 3.5.0.RELEASE.

(Unfortunately the intermediate milestones are not available for download any more since 3.5.0 has been shipped for some time, otherwise you could have tried a binary chop to narrow it down a bit further. Hindsight is a wonderful thing, but perhaps it would be worth upgrading more regularly in future, although I appreciate that can be logistically very tricky.)

Another possibility -- admittedly a bit speculative -- is that you are hitting a similar problem to this thread. The tricky thing in that case is that I wasn't able to reproduce the behaviour, but the situations might be similar - the kernel's instance of Gemini Blueprint might be being used instead of the user region's instance. The most obvious reason would be that the user region properties had been edited and introduced a leakage.

Re: Blueprint problem after moving from 3.5.0.M03 to 3.5.0.RELEASE or 3.6.0.M03 [message #981850 is a reply to message #981312]

Mon, 12 November 2012 13:56

Eclipse User

I found a mirror that still has M03: preview.tinyurl.com/cmr2wa4

The issue does sound similar to the other thread. I'll give a try to switching to Nano.

Another observation is that this seems to be timing related. I had a another bundle that couldn't create an app context with a class from the same bundle and I worked around it by moving it to the beginning of the plan. There is no point in opening a bug until I can create an sample app to reproduce it. I'll give it a try.

Re: Blueprint problem after moving from 3.5.0.M03 to 3.5.0.RELEASE or 3.6.0.M03 [message #982122 is a reply to message #981850]

Mon, 12 November 2012 19:02

Eclipse User

Nano won't work for me because plans are not supported.

When the I strip down the application too much, the issue is no longer occurs. It doesn't happen when the consumer bundle for the service exposed by the problematic bundle is not there. My service hierarchy is a couple layers deep, I won't be able to refactor this into a sample.

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.

Previous Topic:	Monitoring Directories Using Spring Integration
Next Topic:	Virgo vs Hibernate vs Joda

Goto Forum:

-=] Back to Top [=-

Current Time: Sun Jul 27 13:04:30 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter