You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Fabio Fonseca <fa...@gmail.com> on 2012/04/06 22:49:14 UTC
Different components using the same interface inside a composite
Hi All!
I'm trying to make the Comanche SCA example to work with iPOJO. This example
application is a very simple web server and is used everywhere with SCA. The
problem is that different components of this application implements the same
java interface.
In the SCA + Fractal component model world (Frascatti), this is not a
problem, since the software can be assembled by direct referencing the
desired instance. But this is a problem with OSGi/iPOJO, since, as far as I
know, the bind is done automatically and the key for this mechanism is the
unicity of the interface implemented by the component, which identifies the
component.
When not using composites, I found a workaround for this problem by
specifying a name for a instance and using this name in the component
declaration, in the '<requires from="RequestDispatcher"...' key.
However, I'm facing a problem trying to use composite to assemble the
Comanche application. I'm trying to build a composite who encapsulates 3
components that implement the same interface. This composite has to export
one specific instance to be used by the parent scope. To accomplish this, I
did the following XML:
<composite name="RH">
<instance component="FileRH" name="FileRH-Instance"/>
<instance component="ErrorRH" name="ErrorRH-Instance"/>
<instance
component="org.apache.comanche.requestDispatcher.RequestDispatcher"
name="RequestDispatcher"/>
<provides action="export"
specification="org.apache.comanche.services.RequestHandler"/>
</composite>
The problem is: since all three components implements the same
RequestHandler interface, how can I tell the composite to export the
specific RequestDispatcher instance? I tried to use the "name" workaround,
explained above, but it did not work. How can I do it?
Also, I miss a Reference Card like the one found in
(http://felix.apache.org/site/ipojo-reference-card.html) enlightening the
possibilities with composites. Do anyone plan to create something like that?
Thanks in advance!
Fabio
--
View this message in context: http://old.nabble.com/Different-components-using-the-same-interface-inside-a-composite-tp33645498p33645498.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Different components using the same interface inside a composite
Posted by Clement Escoffier <cl...@gmail.com>.
Hi,
On 07.04.2012, at 23:27, Fabio Fonseca wrote:
>
> Hi Clement,
>
> I'm writing again because I managed to solve the option 2 problem... In fact
> there was 2 problems. First of all there was a syntax error in my XML. I
> forgot a "/>" in the first line of the subservice tag, that you can see
> below:
>
> <composite name="comanche.frontend">
> <subservice action="import" />
> specification="org.apache.comanche.services.RequestHandler"
> filter="(instance.name=RequestAnalyzer)" />
> <instance component="org.apache.comanche.requestReceiver.RequestReceiver"
> name="RequestReceiver"/>
> <subservice action="instantiate"
> specification="org.apache.comanche.services.Scheduler"/>
> </composite>
>
> That evil "/>" was the cause for the comanche.frontend instance state be
> "Not Available".
>
> Then, after this small step, the comanche.frontend instance state was still
> "invalid" and, using the arch command, I saw that the required handle was
> invalid too and the cause was the RequestAnalyzer be "unresolved". The
> problem was that the RequestAnalyzer instance I exported in the
> comanche.backend composite was not being found inside the comanche.frontend
> composite, even with the "subservice import" element.
>
> Doing a little more research I found the composite.xsd that gave me the clue
> of the "scope" attribute that I could add to the subservice element. I tried
> to add this attribute to the subservice element as a desperate attempt and
> for my complete surprise it worked! Whether I choose "composite" or
> "composite+global" for its value, it correctly finds the RequestAnalyzer
> instance exported in the comanche.backend composite! :-) On the other hand,
> if I choose the "global" value for the scope attribute, the RequestAnalyzer
> remains hidden.
> So, I learned that whenever I need to import an instance from another
> composite at the same hierarchy level, who properly exports it, I must
> specify the scope in the subservice import element. The scope specification,
> however, is not needed when we instantiate the composite inside another
> composite, as the option 1 case I described below. Is it right?
>
The scope attribute indicates from which level you import your service. Global means that you'r looking only in the root one, while composite indicates you're looking within the composite.
> Unhappily, the error I found when trying this composite with the earlier
> version of the framework, that I described in my previous message, is still
> happening... This one is too low level for my still small knowledge and
> experience with iPOJO.
>
We recently fix a loop in composite when a factory is requiring itself (infinitely). You're probably hitting this bug: https://issues.apache.org/jira/browse/FELIX-3130
Regards,
Clement
> Best regards,
> Fabio
>
>
>
> Fabio Fonseca wrote:
>>
>> Hi Clement,
>>
>> Still regarding compositions with the same interface, I have one more
>> problem when trying to build some hierarchical compositions.
>>
>> 1. Simple hierarchical composition: This is the option that works. I built
>> one composite instantiating a lower level composite, who, in turn,
>> instantiate a even lower level composite, and so on. I have used the tip
>> you gave me in previous messages regarding exporting the right instance.
>> My metadata is the one below:
>>
>> <composite name="comanche.requestHandler">
>> <instance
>> component="org.apache.comanche.requestDispatcher.RequestDispatcher"
>> name="RequestDispatcher"/>
>> <instance component="FileRH"/>
>> <instance component="ErrorRH"/>
>> <provides action="export"
>> specification="org.apache.comanche.services.RequestHandler"
>> filter="(instance.name=RequestDispatcher)" />
>> </composite>
>>
>> <composite name="comanche.backend">
>> <instance component="comanche.requestHandler" name="RequestDispatcher"/>
>> <instance component="org.apache.comanche.requestAnalyzer.RequestAnalyzer"
>> name="RequestAnalyzer"/>
>> <instance component="org.apache.comanche.basicLogger.BasicLogger"/>
>> <provides action="export"
>> specification="org.apache.comanche.services.RequestHandler"
>> filter="(instance.name=RequestAnalyzer)" />
>> </composite>
>>
>> <composite name="comanche.frontend">
>> <instance component="comanche.backend" name="RequestAnalyzer" />
>> <instance component="org.apache.comanche.requestReceiver.RequestReceiver"
>> name="RequestReceiver"/>
>> <subservice action="instantiate"
>> specification="org.apache.comanche.services.Scheduler"/>
>> </composite>
>>
>> <composite name="comanche">
>> <instance component="comanche.frontend"/>
>> </composite>
>>
>> <instance component="comanche"/>
>>
>> 2. Not-so-simple hierarchical composition: This is a variation of the
>> option 1, but with the highest level composite instantiating two lower
>> level composites that provides and requires services from each other.
>> Please see my metadata below:
>>
>> <composite name="comanche.requestHandler">
>> <instance
>> component="org.apache.comanche.requestDispatcher.RequestDispatcher"
>> name="RequestDispatcher"/>
>> <instance component="FileRH"/>
>> <instance component="ErrorRH"/>
>> <provides action="export"
>> specification="org.apache.comanche.services.RequestHandler"
>> filter="(instance.name=RequestDispatcher)" />
>> </composite>
>>
>> <composite name="comanche.backend">
>> <instance component="comanche.requestHandler" name="RequestDispatcher"/>
>> <instance component="org.apache.comanche.requestAnalyzer.RequestAnalyzer"
>> name="RequestAnalyzer"/>
>> <instance component="org.apache.comanche.basicLogger.BasicLogger"/>
>> <provides action="export"
>> specification="org.apache.comanche.services.RequestHandler"
>> filter="(instance.name=RequestAnalyzer)" />
>> </composite>
>>
>> <composite name="comanche.frontend">
>> <subservice action="import"/>
>> specification="org.apache.comanche.services.RequestHandler"
>> filter="(instance.name=RequestAnalyzer)" />
>> <instance component="org.apache.comanche.requestReceiver.RequestReceiver"
>> name="RequestReceiver"/>
>> <subservice action="instantiate"
>> specification="org.apache.comanche.services.Scheduler"/>
>> </composite>
>>
>> <composite name="comanche">
>> <instance component="comanche.backend" name="RequestAnalyzer" />
>> <instance component="comanche.frontend"/>
>> </composite>
>>
>> <instance component="comanche"/>
>>
>> Here, you can see in the bold parts, that I export the RequestAnalyzer
>> service in the comanche.backend composite and import it in the
>> comanche.frontend composite. But it is not working. When I use the arch
>> command to see the internals of my compositions, I see the following:
>>
>> (...)
>> handler name="org.apache.felix.ipojo:instance" state="invalid"
>> instance name="RequestAnalyzer" state="valid" factory="comanche.backend"
>> instance state="Not Available" factory="comanche.frontend"
>> handler name="org.apache.felix.ipojo:architecture" state="valid"
>>
>> It shows that the comanche.frontend, although having a valid factory, does
>> not have a valid instance.
>>
>> Well, I am a bit lost here. I think it may be again a matter of finding
>> the right parameters to the XML to make this composite works. Can you help
>> me?
>>
>> In time: I'm using the framework prepared for composites that we can
>> download from the composite tutorial. It uses the following bundles:
>>
>> -> ps
>> START LEVEL 1
>> ID State Level Name
>> [ 0] [Active ] [ 0] System Bundle (2.0.5)
>> [ 1] [Active ] [ 1] Apache Felix Bundle Repository (1.4.3)
>> [ 2] [Active ] [ 1] Apache Felix iPOJO (1.6.0)
>> [ 3] [Active ] [ 1] Apache Felix iPOJO Arch Command (1.6.0)
>> [ 4] [Active ] [ 1] Apache Felix iPOJO Composite (1.6.0)
>> [ 5] [Active ] [ 1] Apache Felix Log Service (1.0.0)
>> [ 6] [Active ] [ 1] Apache Felix Shell Service (1.4.2)
>> [ 7] [Active ] [ 1] Apache Felix Shell TUI (1.4.1)
>>
>> As a matter of fact, I tried to use the latest version of the framework
>> with iPOJO 1.8.0 and Composite 1.8.0, but it generates a HUGE loop stack
>> trace when I start my composite bundle. It gives me high number of
>> warnings about the "name" attribute, that is deprecated in favor of
>> "instance.name" and the main error is:
>>
>> [ERROR] : The method bindFactory in the implementation class
>> org.apache.felix.ipojo.composite.instance.InstanceHandler throws an
>> exception : null
>> java.lang.StackOverflowError
>> at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>> at java.lang.reflect.Method.invoke(Method.java:597)
>> at org.apache.felix.ipojo.util.Callback.call(Callback.java:260)
>> at
>> org.apache.felix.ipojo.handlers.dependency.DependencyCallback.callOnInstance(DependencyCallback.java:309)
>> at
>> org.apache.felix.ipojo.handlers.dependency.Dependency.invokeCallback(Dependency.java:314)
>> (...)
>>
>>
>> Thanks in advance and best regards!
>> Fabio
>>
>>
>> clement escoffier wrote:
>>>
>>> Hi,
>>>
>>> On 06.04.2012, at 22:49, Fabio Fonseca wrote:
>>>
>>>>
>>>> Hi All!
>>>>
>>>> I'm trying to make the Comanche SCA example to work with iPOJO. This
>>>> example
>>>> application is a very simple web server and is used everywhere with SCA.
>>>> The
>>>> problem is that different components of this application implements the
>>>> same
>>>> java interface.
>>>>
>>>> In the SCA + Fractal component model world (Frascatti), this is not a
>>>> problem, since the software can be assembled by direct referencing the
>>>> desired instance. But this is a problem with OSGi/iPOJO, since, as far
>>>> as I
>>>> know, the bind is done automatically and the key for this mechanism is
>>>> the
>>>> unicity of the interface implemented by the component, which identifies
>>>> the
>>>> component.
>>>>
>>>> When not using composites, I found a workaround for this problem by
>>>> specifying a name for a instance and using this name in the component
>>>> declaration, in the '<requires from="RequestDispatcher"...' key.
>>>>
>>>> However, I'm facing a problem trying to use composite to assemble the
>>>> Comanche application. I'm trying to build a composite who encapsulates 3
>>>> components that implement the same interface. This composite has to
>>>> export
>>>> one specific instance to be used by the parent scope. To accomplish
>>>> this, I
>>>> did the following XML:
>>>>
>>>> <composite name="RH">
>>>> <instance component="FileRH" name="FileRH-Instance"/>
>>>> <instance component="ErrorRH" name="ErrorRH-Instance"/>
>>>> <instance
>>>> component="org.apache.comanche.requestDispatcher.RequestDispatcher"
>>>> name="RequestDispatcher"/>
>>>> <provides action="export"
>>>> specification="org.apache.comanche.services.RequestHandler"/>
>>>> </composite>
>>>>
>>>> The problem is: since all three components implements the same
>>>> RequestHandler interface, how can I tell the composite to export the
>>>> specific RequestDispatcher instance? I tried to use the "name"
>>>> workaround,
>>>> explained above, but it did not work. How can I do it?
>>>
>>> The <provides/> element can have a 'filter' attribute indicating which
>>> service you want to export:
>>> <composite:provides action="export"
>>> specification="..."
>>> filter="(instance.name=RequestDispatcher)" />
>>>
>>>>
>>>> Also, I miss a Reference Card like the one found in
>>>> (http://felix.apache.org/site/ipojo-reference-card.html) enlightening
>>>> the
>>>> possibilities with composites. Do anyone plan to create something like
>>>> that?
>>>>
>>>
>>>
>>> It's planed, but hard to say when….
>>>
>>> Regards,
>>>
>>> Clement
>>>
>>>> Thanks in advance!
>>>> Fabio
>>>> --
>>>> View this message in context:
>>>> http://old.nabble.com/Different-components-using-the-same-interface-inside-a-composite-tp33645498p33645498.html
>>>> Sent from the Apache Felix - Users mailing list archive at Nabble.com.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>>
>>
>>
>
> --
> View this message in context: http://old.nabble.com/Different-components-using-the-same-interface-inside-a-composite-tp33645498p33649920.html
> Sent from the Apache Felix - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
Re: Different components using the same interface inside a
composite
Posted by Fabio Fonseca <fa...@gmail.com>.
Hi Clement,
I'm writing again because I managed to solve the option 2 problem... In fact
there was 2 problems. First of all there was a syntax error in my XML. I
forgot a "/>" in the first line of the subservice tag, that you can see
below:
<composite name="comanche.frontend">
<subservice action="import" />
specification="org.apache.comanche.services.RequestHandler"
filter="(instance.name=RequestAnalyzer)" />
<instance component="org.apache.comanche.requestReceiver.RequestReceiver"
name="RequestReceiver"/>
<subservice action="instantiate"
specification="org.apache.comanche.services.Scheduler"/>
</composite>
That evil "/>" was the cause for the comanche.frontend instance state be
"Not Available".
Then, after this small step, the comanche.frontend instance state was still
"invalid" and, using the arch command, I saw that the required handle was
invalid too and the cause was the RequestAnalyzer be "unresolved". The
problem was that the RequestAnalyzer instance I exported in the
comanche.backend composite was not being found inside the comanche.frontend
composite, even with the "subservice import" element.
Doing a little more research I found the composite.xsd that gave me the clue
of the "scope" attribute that I could add to the subservice element. I tried
to add this attribute to the subservice element as a desperate attempt and
for my complete surprise it worked! Whether I choose "composite" or
"composite+global" for its value, it correctly finds the RequestAnalyzer
instance exported in the comanche.backend composite! :-) On the other hand,
if I choose the "global" value for the scope attribute, the RequestAnalyzer
remains hidden.
So, I learned that whenever I need to import an instance from another
composite at the same hierarchy level, who properly exports it, I must
specify the scope in the subservice import element. The scope specification,
however, is not needed when we instantiate the composite inside another
composite, as the option 1 case I described below. Is it right?
Unhappily, the error I found when trying this composite with the earlier
version of the framework, that I described in my previous message, is still
happening... This one is too low level for my still small knowledge and
experience with iPOJO.
Best regards,
Fabio
Fabio Fonseca wrote:
>
> Hi Clement,
>
> Still regarding compositions with the same interface, I have one more
> problem when trying to build some hierarchical compositions.
>
> 1. Simple hierarchical composition: This is the option that works. I built
> one composite instantiating a lower level composite, who, in turn,
> instantiate a even lower level composite, and so on. I have used the tip
> you gave me in previous messages regarding exporting the right instance.
> My metadata is the one below:
>
> <composite name="comanche.requestHandler">
> <instance
> component="org.apache.comanche.requestDispatcher.RequestDispatcher"
> name="RequestDispatcher"/>
> <instance component="FileRH"/>
> <instance component="ErrorRH"/>
> <provides action="export"
> specification="org.apache.comanche.services.RequestHandler"
> filter="(instance.name=RequestDispatcher)" />
> </composite>
>
> <composite name="comanche.backend">
> <instance component="comanche.requestHandler" name="RequestDispatcher"/>
> <instance component="org.apache.comanche.requestAnalyzer.RequestAnalyzer"
> name="RequestAnalyzer"/>
> <instance component="org.apache.comanche.basicLogger.BasicLogger"/>
> <provides action="export"
> specification="org.apache.comanche.services.RequestHandler"
> filter="(instance.name=RequestAnalyzer)" />
> </composite>
>
> <composite name="comanche.frontend">
> <instance component="comanche.backend" name="RequestAnalyzer" />
> <instance component="org.apache.comanche.requestReceiver.RequestReceiver"
> name="RequestReceiver"/>
> <subservice action="instantiate"
> specification="org.apache.comanche.services.Scheduler"/>
> </composite>
>
> <composite name="comanche">
> <instance component="comanche.frontend"/>
> </composite>
>
> <instance component="comanche"/>
>
> 2. Not-so-simple hierarchical composition: This is a variation of the
> option 1, but with the highest level composite instantiating two lower
> level composites that provides and requires services from each other.
> Please see my metadata below:
>
> <composite name="comanche.requestHandler">
> <instance
> component="org.apache.comanche.requestDispatcher.RequestDispatcher"
> name="RequestDispatcher"/>
> <instance component="FileRH"/>
> <instance component="ErrorRH"/>
> <provides action="export"
> specification="org.apache.comanche.services.RequestHandler"
> filter="(instance.name=RequestDispatcher)" />
> </composite>
>
> <composite name="comanche.backend">
> <instance component="comanche.requestHandler" name="RequestDispatcher"/>
> <instance component="org.apache.comanche.requestAnalyzer.RequestAnalyzer"
> name="RequestAnalyzer"/>
> <instance component="org.apache.comanche.basicLogger.BasicLogger"/>
> <provides action="export"
> specification="org.apache.comanche.services.RequestHandler"
> filter="(instance.name=RequestAnalyzer)" />
> </composite>
>
> <composite name="comanche.frontend">
> <subservice action="import"/>
> specification="org.apache.comanche.services.RequestHandler"
> filter="(instance.name=RequestAnalyzer)" />
> <instance component="org.apache.comanche.requestReceiver.RequestReceiver"
> name="RequestReceiver"/>
> <subservice action="instantiate"
> specification="org.apache.comanche.services.Scheduler"/>
> </composite>
>
> <composite name="comanche">
> <instance component="comanche.backend" name="RequestAnalyzer" />
> <instance component="comanche.frontend"/>
> </composite>
>
> <instance component="comanche"/>
>
> Here, you can see in the bold parts, that I export the RequestAnalyzer
> service in the comanche.backend composite and import it in the
> comanche.frontend composite. But it is not working. When I use the arch
> command to see the internals of my compositions, I see the following:
>
> (...)
> handler name="org.apache.felix.ipojo:instance" state="invalid"
> instance name="RequestAnalyzer" state="valid" factory="comanche.backend"
> instance state="Not Available" factory="comanche.frontend"
> handler name="org.apache.felix.ipojo:architecture" state="valid"
>
> It shows that the comanche.frontend, although having a valid factory, does
> not have a valid instance.
>
> Well, I am a bit lost here. I think it may be again a matter of finding
> the right parameters to the XML to make this composite works. Can you help
> me?
>
> In time: I'm using the framework prepared for composites that we can
> download from the composite tutorial. It uses the following bundles:
>
> -> ps
> START LEVEL 1
> ID State Level Name
> [ 0] [Active ] [ 0] System Bundle (2.0.5)
> [ 1] [Active ] [ 1] Apache Felix Bundle Repository (1.4.3)
> [ 2] [Active ] [ 1] Apache Felix iPOJO (1.6.0)
> [ 3] [Active ] [ 1] Apache Felix iPOJO Arch Command (1.6.0)
> [ 4] [Active ] [ 1] Apache Felix iPOJO Composite (1.6.0)
> [ 5] [Active ] [ 1] Apache Felix Log Service (1.0.0)
> [ 6] [Active ] [ 1] Apache Felix Shell Service (1.4.2)
> [ 7] [Active ] [ 1] Apache Felix Shell TUI (1.4.1)
>
> As a matter of fact, I tried to use the latest version of the framework
> with iPOJO 1.8.0 and Composite 1.8.0, but it generates a HUGE loop stack
> trace when I start my composite bundle. It gives me high number of
> warnings about the "name" attribute, that is deprecated in favor of
> "instance.name" and the main error is:
>
> [ERROR] : The method bindFactory in the implementation class
> org.apache.felix.ipojo.composite.instance.InstanceHandler throws an
> exception : null
> java.lang.StackOverflowError
> at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.apache.felix.ipojo.util.Callback.call(Callback.java:260)
> at
> org.apache.felix.ipojo.handlers.dependency.DependencyCallback.callOnInstance(DependencyCallback.java:309)
> at
> org.apache.felix.ipojo.handlers.dependency.Dependency.invokeCallback(Dependency.java:314)
> (...)
>
>
> Thanks in advance and best regards!
> Fabio
>
>
> clement escoffier wrote:
>>
>> Hi,
>>
>> On 06.04.2012, at 22:49, Fabio Fonseca wrote:
>>
>>>
>>> Hi All!
>>>
>>> I'm trying to make the Comanche SCA example to work with iPOJO. This
>>> example
>>> application is a very simple web server and is used everywhere with SCA.
>>> The
>>> problem is that different components of this application implements the
>>> same
>>> java interface.
>>>
>>> In the SCA + Fractal component model world (Frascatti), this is not a
>>> problem, since the software can be assembled by direct referencing the
>>> desired instance. But this is a problem with OSGi/iPOJO, since, as far
>>> as I
>>> know, the bind is done automatically and the key for this mechanism is
>>> the
>>> unicity of the interface implemented by the component, which identifies
>>> the
>>> component.
>>>
>>> When not using composites, I found a workaround for this problem by
>>> specifying a name for a instance and using this name in the component
>>> declaration, in the '<requires from="RequestDispatcher"...' key.
>>>
>>> However, I'm facing a problem trying to use composite to assemble the
>>> Comanche application. I'm trying to build a composite who encapsulates 3
>>> components that implement the same interface. This composite has to
>>> export
>>> one specific instance to be used by the parent scope. To accomplish
>>> this, I
>>> did the following XML:
>>>
>>> <composite name="RH">
>>> <instance component="FileRH" name="FileRH-Instance"/>
>>> <instance component="ErrorRH" name="ErrorRH-Instance"/>
>>> <instance
>>> component="org.apache.comanche.requestDispatcher.RequestDispatcher"
>>> name="RequestDispatcher"/>
>>> <provides action="export"
>>> specification="org.apache.comanche.services.RequestHandler"/>
>>> </composite>
>>>
>>> The problem is: since all three components implements the same
>>> RequestHandler interface, how can I tell the composite to export the
>>> specific RequestDispatcher instance? I tried to use the "name"
>>> workaround,
>>> explained above, but it did not work. How can I do it?
>>
>> The <provides/> element can have a 'filter' attribute indicating which
>> service you want to export:
>> <composite:provides action="export"
>> specification="..."
>> filter="(instance.name=RequestDispatcher)" />
>>
>>>
>>> Also, I miss a Reference Card like the one found in
>>> (http://felix.apache.org/site/ipojo-reference-card.html) enlightening
>>> the
>>> possibilities with composites. Do anyone plan to create something like
>>> that?
>>>
>>
>>
>> It's planed, but hard to say when….
>>
>> Regards,
>>
>> Clement
>>
>>> Thanks in advance!
>>> Fabio
>>> --
>>> View this message in context:
>>> http://old.nabble.com/Different-components-using-the-same-interface-inside-a-composite-tp33645498p33645498.html
>>> Sent from the Apache Felix - Users mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>>
>
>
--
View this message in context: http://old.nabble.com/Different-components-using-the-same-interface-inside-a-composite-tp33645498p33649920.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Different components using the same interface inside a
composite
Posted by Fabio Fonseca <fa...@gmail.com>.
Hi Clement,
Still regarding compositions with the same interface, I have one more
problem when trying to build some hierarchical compositions.
1. Simple hierarchical composition: This is the option that works. I built
one composite instantiating a lower level composite, who, in turn,
instantiate a even lower level composite, and so on. I have used the tip you
gave me in previous messages regarding exporting the right instance. My
metadata is the one below:
<composite name="comanche.requestHandler">
<instance
component="org.apache.comanche.requestDispatcher.RequestDispatcher"
name="RequestDispatcher"/>
<instance component="FileRH"/>
<instance component="ErrorRH"/>
<provides action="export"
specification="org.apache.comanche.services.RequestHandler"
filter="(instance.name=RequestDispatcher)" />
</composite>
<composite name="comanche.backend">
<instance component="comanche.requestHandler" name="RequestDispatcher"/>
<instance component="org.apache.comanche.requestAnalyzer.RequestAnalyzer"
name="RequestAnalyzer"/>
<instance component="org.apache.comanche.basicLogger.BasicLogger"/>
<provides action="export"
specification="org.apache.comanche.services.RequestHandler"
filter="(instance.name=RequestAnalyzer)" />
</composite>
<composite name="comanche.frontend">
<instance component="comanche.backend" name="RequestAnalyzer" />
<instance component="org.apache.comanche.requestReceiver.RequestReceiver"
name="RequestReceiver"/>
<subservice action="instantiate"
specification="org.apache.comanche.services.Scheduler"/>
</composite>
<composite name="comanche">
<instance component="comanche.frontend"/>
</composite>
<instance component="comanche"/>
2. Not-so-simple hierarchical composition: This is a variation of the option
1, but with the highest level composite instantiating two lower level
composites that provides and requires services from each other. Please see
my metadata below:
<composite name="comanche.requestHandler">
<instance
component="org.apache.comanche.requestDispatcher.RequestDispatcher"
name="RequestDispatcher"/>
<instance component="FileRH"/>
<instance component="ErrorRH"/>
<provides action="export"
specification="org.apache.comanche.services.RequestHandler"
filter="(instance.name=RequestDispatcher)" />
</composite>
<composite name="comanche.backend">
<instance component="comanche.requestHandler" name="RequestDispatcher"/>
<instance component="org.apache.comanche.requestAnalyzer.RequestAnalyzer"
name="RequestAnalyzer"/>
<instance component="org.apache.comanche.basicLogger.BasicLogger"/>
<provides action="export"
specification="org.apache.comanche.services.RequestHandler"
filter="(instance.name=RequestAnalyzer)" />
</composite>
<composite name="comanche.frontend">
<subservice action="import"/>
specification="org.apache.comanche.services.RequestHandler"
filter="(instance.name=RequestAnalyzer)" />
<instance component="org.apache.comanche.requestReceiver.RequestReceiver"
name="RequestReceiver"/>
<subservice action="instantiate"
specification="org.apache.comanche.services.Scheduler"/>
</composite>
<composite name="comanche">
<instance component="comanche.backend" name="RequestAnalyzer" />
<instance component="comanche.frontend"/>
</composite>
<instance component="comanche"/>
Here, you can see in the bold parts, that I export the RequestAnalyzer
service in the comanche.backend composite and import it in the
comanche.frontend composite. But it is not working. When I use the arch
command to see the internals of my compositions, I see the following:
(...)
handler name="org.apache.felix.ipojo:instance" state="invalid"
instance name="RequestAnalyzer" state="valid" factory="comanche.backend"
instance state="Not Available" factory="comanche.frontend"
handler name="org.apache.felix.ipojo:architecture" state="valid"
It shows that the comanche.frontend, although having a valid factory, does
not have a valid instance.
Well, I am a bit lost here. I think it may be again a matter of finding the
right parameters to the XML to make this composite works. Can you help me?
In time: I'm using the framework prepared for composites that we can
download from the composite tutorial. It uses the following bundles:
-> ps
START LEVEL 1
ID State Level Name
[ 0] [Active ] [ 0] System Bundle (2.0.5)
[ 1] [Active ] [ 1] Apache Felix Bundle Repository (1.4.3)
[ 2] [Active ] [ 1] Apache Felix iPOJO (1.6.0)
[ 3] [Active ] [ 1] Apache Felix iPOJO Arch Command (1.6.0)
[ 4] [Active ] [ 1] Apache Felix iPOJO Composite (1.6.0)
[ 5] [Active ] [ 1] Apache Felix Log Service (1.0.0)
[ 6] [Active ] [ 1] Apache Felix Shell Service (1.4.2)
[ 7] [Active ] [ 1] Apache Felix Shell TUI (1.4.1)
As a matter of fact, I tried to use the latest version of the framework with
iPOJO 1.8.0 and Composite 1.8.0, but it generates a HUGE loop stack trace
when I start my composite bundle. It gives me high number of warnings about
the "name" attribute, that is deprecated in favor of "instance.name" and the
main error is:
[ERROR] : The method bindFactory in the implementation class
org.apache.felix.ipojo.composite.instance.InstanceHandler throws an
exception : null
java.lang.StackOverflowError
at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.felix.ipojo.util.Callback.call(Callback.java:260)
at
org.apache.felix.ipojo.handlers.dependency.DependencyCallback.callOnInstance(DependencyCallback.java:309)
at
org.apache.felix.ipojo.handlers.dependency.Dependency.invokeCallback(Dependency.java:314)
(...)
Thanks in advance and best regards!
Fabio
clement escoffier wrote:
>
> Hi,
>
> On 06.04.2012, at 22:49, Fabio Fonseca wrote:
>
>>
>> Hi All!
>>
>> I'm trying to make the Comanche SCA example to work with iPOJO. This
>> example
>> application is a very simple web server and is used everywhere with SCA.
>> The
>> problem is that different components of this application implements the
>> same
>> java interface.
>>
>> In the SCA + Fractal component model world (Frascatti), this is not a
>> problem, since the software can be assembled by direct referencing the
>> desired instance. But this is a problem with OSGi/iPOJO, since, as far as
>> I
>> know, the bind is done automatically and the key for this mechanism is
>> the
>> unicity of the interface implemented by the component, which identifies
>> the
>> component.
>>
>> When not using composites, I found a workaround for this problem by
>> specifying a name for a instance and using this name in the component
>> declaration, in the '<requires from="RequestDispatcher"...' key.
>>
>> However, I'm facing a problem trying to use composite to assemble the
>> Comanche application. I'm trying to build a composite who encapsulates 3
>> components that implement the same interface. This composite has to
>> export
>> one specific instance to be used by the parent scope. To accomplish this,
>> I
>> did the following XML:
>>
>> <composite name="RH">
>> <instance component="FileRH" name="FileRH-Instance"/>
>> <instance component="ErrorRH" name="ErrorRH-Instance"/>
>> <instance
>> component="org.apache.comanche.requestDispatcher.RequestDispatcher"
>> name="RequestDispatcher"/>
>> <provides action="export"
>> specification="org.apache.comanche.services.RequestHandler"/>
>> </composite>
>>
>> The problem is: since all three components implements the same
>> RequestHandler interface, how can I tell the composite to export the
>> specific RequestDispatcher instance? I tried to use the "name"
>> workaround,
>> explained above, but it did not work. How can I do it?
>
> The <provides/> element can have a 'filter' attribute indicating which
> service you want to export:
> <composite:provides action="export"
> specification="..."
> filter="(instance.name=RequestDispatcher)" />
>
>>
>> Also, I miss a Reference Card like the one found in
>> (http://felix.apache.org/site/ipojo-reference-card.html) enlightening the
>> possibilities with composites. Do anyone plan to create something like
>> that?
>>
>
>
> It's planed, but hard to say when….
>
> Regards,
>
> Clement
>
>> Thanks in advance!
>> Fabio
>> --
>> View this message in context:
>> http://old.nabble.com/Different-components-using-the-same-interface-inside-a-composite-tp33645498p33645498.html
>> Sent from the Apache Felix - Users mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
>
--
View this message in context: http://old.nabble.com/Different-components-using-the-same-interface-inside-a-composite-tp33645498p33648909.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Different components using the same interface inside a
composite
Posted by Fabio Fonseca <fa...@gmail.com>.
Hi Clement!
Thank you very much! You and Richard are solving a lot of problems to me!
:-)
I did what you suggest and it worked fine. But there is one more step for it
to work: As I am using the <requires from="..."> in the RequestAnalyzer
component declaration, for it to be bound with the right instance, just
export the right service was not enough. I had also to name the instance of
my composite with the name I used in the <requires from="..."> as in the
example below:
<composite name="RD">
<instance component="RH" />
<instance
component="org.apache.comanche.requestDispatcher.RequestDispatcher"
name="RequestDispatcher"/>
<provides action="export"
specification="org.apache.comanche.services.RequestHandler"
filter="(instance.name=RequestDispatcher)" />
</composite>
<composite name="comanche">
<instance component="RD" name="RequestDispatcher"/>
<instance component="org.apache.comanche.requestAnalyzer.RequestAnalyzer"
name="RequestAnalyzer"/>
<instance component="org.apache.comanche.basicLogger.BasicLogger"/>
<instance
component="org.apache.comanche.multiThreadScheduler.MultiThreadScheduler"/>
<instance
component="org.apache.comanche.sequentialScheduler.SequentialScheduler"/>
<instance component="org.apache.comanche.requestReceiver.RequestReceiver"
name="RequestReceiver"/>
</composite>
I'm writing this here just for a matter of documentation, as other people
may have the same problem I had.
One last question: I have mentioned the Reference Card for composite because
it could have solved my problem without having to ask you directly. I know
documenting is the boring part, but do you have anything else besides the
composite tutorial that teaches us the details of ipojo composite model? I
have searched internet but so far I found nothing as detailed as the
composite tutorial.
Thanks a lot for your valuable help!
Fabio
clement escoffier wrote:
>
> Hi,
>
> On 06.04.2012, at 22:49, Fabio Fonseca wrote:
>
>>
>> Hi All!
>>
>> I'm trying to make the Comanche SCA example to work with iPOJO. This
>> example
>> application is a very simple web server and is used everywhere with SCA.
>> The
>> problem is that different components of this application implements the
>> same
>> java interface.
>>
>> In the SCA + Fractal component model world (Frascatti), this is not a
>> problem, since the software can be assembled by direct referencing the
>> desired instance. But this is a problem with OSGi/iPOJO, since, as far as
>> I
>> know, the bind is done automatically and the key for this mechanism is
>> the
>> unicity of the interface implemented by the component, which identifies
>> the
>> component.
>>
>> When not using composites, I found a workaround for this problem by
>> specifying a name for a instance and using this name in the component
>> declaration, in the '<requires from="RequestDispatcher"...' key.
>>
>> However, I'm facing a problem trying to use composite to assemble the
>> Comanche application. I'm trying to build a composite who encapsulates 3
>> components that implement the same interface. This composite has to
>> export
>> one specific instance to be used by the parent scope. To accomplish this,
>> I
>> did the following XML:
>>
>> <composite name="RH">
>> <instance component="FileRH" name="FileRH-Instance"/>
>> <instance component="ErrorRH" name="ErrorRH-Instance"/>
>> <instance
>> component="org.apache.comanche.requestDispatcher.RequestDispatcher"
>> name="RequestDispatcher"/>
>> <provides action="export"
>> specification="org.apache.comanche.services.RequestHandler"/>
>> </composite>
>>
>> The problem is: since all three components implements the same
>> RequestHandler interface, how can I tell the composite to export the
>> specific RequestDispatcher instance? I tried to use the "name"
>> workaround,
>> explained above, but it did not work. How can I do it?
>
> The <provides/> element can have a 'filter' attribute indicating which
> service you want to export:
> <composite:provides action="export"
> specification="..."
> filter="(instance.name=RequestDispatcher)" />
>
>>
>> Also, I miss a Reference Card like the one found in
>> (http://felix.apache.org/site/ipojo-reference-card.html) enlightening the
>> possibilities with composites. Do anyone plan to create something like
>> that?
>>
>
>
> It's planed, but hard to say when….
>
> Regards,
>
> Clement
>
>> Thanks in advance!
>> Fabio
>> --
>> View this message in context:
>> http://old.nabble.com/Different-components-using-the-same-interface-inside-a-composite-tp33645498p33645498.html
>> Sent from the Apache Felix - Users mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
>
--
View this message in context: http://old.nabble.com/Different-components-using-the-same-interface-inside-a-composite-tp33645498p33648701.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Different components using the same interface inside a composite
Posted by Clement Escoffier <cl...@gmail.com>.
Hi,
On 06.04.2012, at 22:49, Fabio Fonseca wrote:
>
> Hi All!
>
> I'm trying to make the Comanche SCA example to work with iPOJO. This example
> application is a very simple web server and is used everywhere with SCA. The
> problem is that different components of this application implements the same
> java interface.
>
> In the SCA + Fractal component model world (Frascatti), this is not a
> problem, since the software can be assembled by direct referencing the
> desired instance. But this is a problem with OSGi/iPOJO, since, as far as I
> know, the bind is done automatically and the key for this mechanism is the
> unicity of the interface implemented by the component, which identifies the
> component.
>
> When not using composites, I found a workaround for this problem by
> specifying a name for a instance and using this name in the component
> declaration, in the '<requires from="RequestDispatcher"...' key.
>
> However, I'm facing a problem trying to use composite to assemble the
> Comanche application. I'm trying to build a composite who encapsulates 3
> components that implement the same interface. This composite has to export
> one specific instance to be used by the parent scope. To accomplish this, I
> did the following XML:
>
> <composite name="RH">
> <instance component="FileRH" name="FileRH-Instance"/>
> <instance component="ErrorRH" name="ErrorRH-Instance"/>
> <instance
> component="org.apache.comanche.requestDispatcher.RequestDispatcher"
> name="RequestDispatcher"/>
> <provides action="export"
> specification="org.apache.comanche.services.RequestHandler"/>
> </composite>
>
> The problem is: since all three components implements the same
> RequestHandler interface, how can I tell the composite to export the
> specific RequestDispatcher instance? I tried to use the "name" workaround,
> explained above, but it did not work. How can I do it?
The <provides/> element can have a 'filter' attribute indicating which service you want to export:
<composite:provides action="export"
specification="..."
filter="(instance.name=RequestDispatcher)" />
>
> Also, I miss a Reference Card like the one found in
> (http://felix.apache.org/site/ipojo-reference-card.html) enlightening the
> possibilities with composites. Do anyone plan to create something like that?
>
It's planed, but hard to say when….
Regards,
Clement
> Thanks in advance!
> Fabio
> --
> View this message in context: http://old.nabble.com/Different-components-using-the-same-interface-inside-a-composite-tp33645498p33645498.html
> Sent from the Apache Felix - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org