Hi Tim
Here is the full call stack of the exception.
org.osgi.service.blueprint.container.ComponentDefinitionException: Unable to
find a matching factory method createBean on class
ch.suisa.common.utils.BeanFactory for arguments
[org.apache.aries.blueprint.container.BeanRecipe$UnwrapperedBeanHolder@2ae73efd]
when instanciating bean extBean
at
org.apache.aries.blueprint.container.BeanRecipe.getInstance(BeanRecipe.java:303)[8:org.apache.aries.blueprint.core:1.0.1.fuse-71-047]
at
org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:806)[8:org.apache.aries.blueprint.core:1.0.1.fuse-71-047]
at
org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:787)[8:org.apache.aries.blueprint.core:1.0.1.fuse-71-047]
at
org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)[8:org.apache.aries.blueprint.core:1.0.1.fuse-71-047]
at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)[:1.7.0_04]
at java.util.concurrent.FutureTask.run(FutureTask.java:166)[:1.7.0_04]
at
org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)[8:org.apache.aries.blueprint.core:1.0.1.fuse-71-047]
at
org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:245)[8:org.apache.aries.blueprint.core:1.0.1.fuse-71-047]
at
org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:183)[8:org.apache.aries.blueprint.core:1.0.1.fuse-71-047]
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:649)[8:org.apache.aries.blueprint.core:1.0.1.fuse-71-047]
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:356)[8:org.apache.aries.blueprint.core:1.0.1.fuse-71-047]
at
org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:255)[8:org.apache.aries.blueprint.core:1.0.1.fuse-71-047]
at
org.apache.aries.blueprint.container.BlueprintExtender.checkBundle(BlueprintExtender.java:325)[8:org.apache.aries.blueprint.core:1.0.1.fuse-71-047]
at
org.apache.aries.blueprint.container.BlueprintExtender.bundleChanged(BlueprintExtender.java:243)[8:org.apache.aries.blueprint.core:1.0.1.fuse-71-047]
at
org.apache.aries.blueprint.container.BlueprintExtender$BlueprintBundleTrackerCustomizer.modifiedBundle(BlueprintExtender.java:471)[8:org.apache.aries.blueprint.core:1.0.1.fuse-71-047]
at
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:198)[10:org.apache.aries.util:1.0.0]
at
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:128)[10:org.apache.aries.util:1.0.0]
at
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$AbstractTracked.track(BundleHookBundleTracker.java:468)[10:org.apache.aries.util:1.0.0]
at
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.bundleChanged(BundleHookBundleTracker.java:161)[10:org.apache.aries.util:1.0.0]
at
org.apache.aries.util.tracker.hook.BundleHookBundleTracker$BundleEventHook.event(BundleHookBundleTracker.java:117)[10:org.apache.aries.util:1.0.0]
at
org.apache.felix.framework.util.SecureAction.invokeBundleEventHook(SecureAction.java:1103)[org.apache.felix.framework-4.0.3.fuse-71-047.jar:]
at
org.apache.felix.framework.util.EventDispatcher.createWhitelistFromHooks(EventDispatcher.java:696)[org.apache.felix.framework-4.0.3.fuse-71-047.jar:]
at
org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:484)[org.apache.felix.framework-4.0.3.fuse-71-047.jar:]
at
org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4479)[org.apache.felix.framework-4.0.3.fuse-71-047.jar:]
at
org.apache.felix.framework.Felix$4.run(Felix.java:2019)[org.apache.felix.framework-4.0.3.fuse-71-047.jar:]
at
org.apache.felix.framework.Felix$5.run(Felix.java:2061)[org.apache.felix.framework-4.0.3.fuse-71-047.jar:]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)[:1.7.0_04]
at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)[:1.7.0_04]
at java.util.concurrent.FutureTask.run(FutureTask.java:166)[:1.7.0_04]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)[:1.7.0_04]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)[:1.7.0_04]
at java.lang.Thread.run(Thread.java:722)[:1.7.0_04]
We are able to work around it by introducing an additional layer and separating
the transaction functionality from the rest.
I will try to open a bug in JIRA.
Regards
Daniel
Von: [email protected] [[email protected]]" im Auftrag von
"Timothy Ward [[email protected]]
Gesendet: Montag, 28. Januar 2013 15:01
An: [email protected]
Betreff: RE: AW: Problem with ref argument in Aries 1.0
Hi Daniel.
I'm assuming that there was a stack trace from the
ComponentDefinitionException? This looks like a problem introduced by the
inter-bean proxying that Aries started doing some time around 0.4. If you could
put together the information from this thread in a bug in Aries JIRA then we
should be able to do something about it in the next 1.0.x release. Hopefully
this is something you can work around in the interim?
Regards
Tim Ward
-------------------
Apache Aries PMC member & Enterprise OSGi advocate
Enterprise OSGi in Action (http://www.manning.com/cummins)
-------------------
> From: [email protected]
> To: [email protected]
> Subject: AW: Problem with ref argument in Aries 1.0
> Date: Mon, 28 Jan 2013 06:42:59 +0000
>
> The problem can be shown with just a very simple BeanFactory:
>
> public class BeanFactory {
> public SimpleBean createBean(SimpleBean bean) {
> return bean;
> }
> }
>
> Of course my real factory would be much more complex.
>
> Daniel
>
>
> Von: Emily Jiang [[email protected]]
> Gesendet: Donnerstag, 24. Januar 2013 23:11
> An: [email protected]
> Betreff: Re: Problem with ref argument in Aries 1.0
>
>
> Can you paste your BeanFactory class here?
>
>
>
> On Thu, Jan 17, 2013 at 6:24 AM, Zweifel, Daniel <[email protected]>
> wrote:
>
> SimpleBean is a very simple bean;-):
>
> public class SimpleBean {
> public SimpleBean() { }
> }
>
> And it makes no difference if there is a constructor or not.
>
>
> Daniel
>
> ________________________________________
> Von: Daniel Kulp [[email protected]]
> Gesendet: Mittwoch, 16. Januar 2013 18:57
> An: [email protected]; Zweifel, Daniel
> Betreff: Re: Problem with ref argument in Aries 1.0
>
>
> Does SimpleBean have a public no-arg constructor? If not, can you add one?
>
>
> Dan
>
>
>
> On Jan 16, 2013, at 3:55 AM, "Zweifel, Daniel" <[email protected]>
> wrote:
>
> > This is a copy of my post to the Fuse ESB forum
> > (http://fusesource.com/forums/thread.jspa?threadID=4554&tstart=0), because
> > it's an Aries problem.
> >
> >
> > Hi all
> >
> > I have discovered a problem with ref arguments in Fuse 7.1.0 (Aries 1.0).
> >
> > With Fuse 7.0.0 (Aries 0.3) this was working:
> >
> > <bean id="factoryBean" class="ch.suisa.common.BeanFactory"/>
> > <bean id="simpleBean" class="ch.suisa.common.SimpleBean">
> > <tx:transaction method="*" value="Required" />
> > </bean>
> > <bean id="extBean" factory-ref="factoryBean" factory-method="createBean">
> > <argument ref="simpleBean"/>
> > </bean>
> >
> > Now I get an exception when starting the bundle:
> > org.osgi.service.blueprint.container.ComponentDefinitionException: Unable
> > to find a matching factory method createBean on class
> > ch.suisa.common.BeanFactory for arguments
> > org.apache.aries.blueprint.container.BeanRecipe$UnwrapperedBeanHolder@10867a57
> > when instanciating bean extBean
> >
> > The problem seems to be the tx:transaction decoration on simpleBean. When I
> > leave this away, I can start the bundle.
> >
> > Is this a bug or intended behaviour?
> >
> >
> > Daniel
>
> --
> Daniel Kulp
> [email protected] - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>
>
> --
> Thanks
> Emily
> =================
> Emily Jiang
> [email protected]
