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