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: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
>
--
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: [email protected]
For additional commands, e-mail: [email protected]
