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: [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-tp33645498p33649920.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]
