You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@aries.apache.org by "Zweifel, Daniel" <Da...@adesso.ch> on 2013/01/16 09:55:10 UTC
Problem with ref argument in Aries 1.0
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
AW: AW: Problem with ref argument in Aries 1.0
Posted by "Zweifel, Daniel" <Da...@adesso.ch>.
I created JIRA bug ARIES-1008 for this.
________________________________________
Von: Zweifel, Daniel [Daniel.Zweifel@adesso.ch]
Gesendet: Dienstag, 29. Januar 2013 08:19
An: user@aries.apache.org
Betreff: AW: AW: Problem with ref argument in Aries 1.0
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: timothyjward@hotmail.com [timothyjward@hotmail.com]" im Auftrag von "Timothy Ward [timothyjward@apache.org]
Gesendet: Montag, 28. Januar 2013 15:01
An: user@aries.apache.org
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: Daniel.Zweifel@adesso.ch
> To: user@aries.apache.org
> 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 [emijiang6@googlemail.com]
> Gesendet: Donnerstag, 24. Januar 2013 23:11
> An: user@aries.apache.org
> 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 <Da...@adesso.ch> 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 [dkulp@apache.org]
> Gesendet: Mittwoch, 16. Januar 2013 18:57
> An: user@aries.apache.org; 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" <Da...@adesso.ch> 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
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>
>
> --
> Thanks
> Emily
> =================
> Emily Jiang
> ejiang@apache.org
AW: AW: Problem with ref argument in Aries 1.0
Posted by "Zweifel, Daniel" <Da...@adesso.ch>.
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: timothyjward@hotmail.com [timothyjward@hotmail.com]" im Auftrag von "Timothy Ward [timothyjward@apache.org]
Gesendet: Montag, 28. Januar 2013 15:01
An: user@aries.apache.org
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: Daniel.Zweifel@adesso.ch
> To: user@aries.apache.org
> 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 [emijiang6@googlemail.com]
> Gesendet: Donnerstag, 24. Januar 2013 23:11
> An: user@aries.apache.org
> 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 <Da...@adesso.ch> 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 [dkulp@apache.org]
> Gesendet: Mittwoch, 16. Januar 2013 18:57
> An: user@aries.apache.org; 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" <Da...@adesso.ch> 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
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>
>
> --
> Thanks
> Emily
> =================
> Emily Jiang
> ejiang@apache.org
RE: AW: Problem with ref argument in Aries 1.0
Posted by Timothy Ward <ti...@apache.org>.
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: Daniel.Zweifel@adesso.ch
> To: user@aries.apache.org
> 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 [emijiang6@googlemail.com]
> Gesendet: Donnerstag, 24. Januar 2013 23:11
> An: user@aries.apache.org
> 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 <Da...@adesso.ch> 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 [dkulp@apache.org]
> Gesendet: Mittwoch, 16. Januar 2013 18:57
> An: user@aries.apache.org; 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" <Da...@adesso.ch> 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
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
>
>
> --
> Thanks
> Emily
> =================
> Emily Jiang
> ejiang@apache.org
AW: Problem with ref argument in Aries 1.0
Posted by "Zweifel, Daniel" <Da...@adesso.ch>.
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 [emijiang6@googlemail.com]
Gesendet: Donnerstag, 24. Januar 2013 23:11
An: user@aries.apache.org
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 <Da...@adesso.ch> 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 [dkulp@apache.org]
Gesendet: Mittwoch, 16. Januar 2013 18:57
An: user@aries.apache.org; 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" <Da...@adesso.ch> 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
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
--
Thanks
Emily
=================
Emily Jiang
ejiang@apache.org
Re: Problem with ref argument in Aries 1.0
Posted by Emily Jiang <em...@googlemail.com>.
Can you paste your BeanFactory class here?
On Thu, Jan 17, 2013 at 6:24 AM, Zweifel, Daniel
<Da...@adesso.ch>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 [dkulp@apache.org]
> Gesendet: Mittwoch, 16. Januar 2013 18:57
> An: user@aries.apache.org; 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" <Da...@adesso.ch>
> 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@10867a57when 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
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
--
Thanks
Emily
=================
Emily Jiang
ejiang@apache.org
AW: Problem with ref argument in Aries 1.0
Posted by "Zweifel, Daniel" <Da...@adesso.ch>.
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 [dkulp@apache.org]
Gesendet: Mittwoch, 16. Januar 2013 18:57
An: user@aries.apache.org; 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" <Da...@adesso.ch> 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
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Problem with ref argument in Aries 1.0
Posted by Daniel Kulp <dk...@apache.org>.
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" <Da...@adesso.ch> 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
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com