Hello,
Richard is right, you can do that with composites. A composite is a ...
composition of components or services.
So, in your case, let's imagine 3 implementation classes like:
@Component
@Provides(specifications= {A.class})
public class A {
public String doSomething() {
return "A";
}
}
@Component
@Provides(specifications= {B.class})
public class B {
@Requires
private A myA;
public String doSomething() {
return "B -> " + myA.doSomething();
}
}
@Component
public class C {
@Requires
private B myB;
@Validate
public void start() {
System.out.println("Call C -> " + myB.doSomething());
}
}
Two things to note:
- A and B provide themselves as 'service'. Despite (like Richard) I do not
recommend such practice, iPOJO supports that.
- B and C deal with the bound component with simple service dependencies.
So, you can argue that you don't want global services there. That's where
composites comes into the games. Composites provide a service isolation
mechanism. So services exposed inside a composite are not exposed outside
(except if they are voluntary exported).
Let's create such composition:
<ipojo>
<composite name="MyApp">
<instance component="org.apache.felix.ipojo.sample.A"/>
<instance component="org.apache.felix.ipojo.sample.B"/>
<instance component="org.apache.felix.ipojo.sample.C"/>
</composite>
<instance component="MyApp"/>
</ipojo>
That's it. You just declare an instance of A, B and C. As bindings are
service-based, it's automatic. As said above, the services exposed inside
the composite are not exposed outside.
So, once deployed, something like 'Call C -> B-> A' appears.
If you want to specify bindings more finely, yo can write something like:
...
<instance component="org.apache.felix.ipojo.sample.A" instance.name
="myA"/>
<instance component="org.apache.felix.ipojo.sample.B">
<property name="requires.from">
<property name="org.apache.felix.ipojo.sample.A" value="myA"/>
</property>
</instance>
...
When you're application works, you can reduce binding coupling by replacing
the instance declarations by instantiated sub-services (iPOJO will looks for
a component type providing your specification).
I recommend you to read
http://felix.apache.org/site/ipojo-composition-tutorial.html to know more
about iPOJO compositions.
Regards,
Clement
2009/8/7 Richard S. Hall <[email protected]>
> On 8/7/09 11:35, André Lage wrote:
>
>> Hi all!
>>
>> I'm interested in knowing how I could compose iPOJO components, but only
>> in terms of components. Let me better explain.
>>
>> Imagine that I am a service developer (a single service developer). In
>> this case, from the OSGi point of view, I should implement a Java interface
>> that describes/represents this service and then publish my service (suppose
>> that there is only this service inside of a bundle). But before implementing
>> this interface, I need to well design and develop my component-based
>> application.
>>
>> In other words, I need to take advantage of the iPOJO component model when
>> composing *without taking into account services*, I just want to plug/unplug
>> components. In some tutorials, I could only see relationships among iPOJO
>> components through OSGi services.
>>
>> Let's take an example: suppose that the following illustration is my
>> application design (a single OSGi service inside of a bundle):
>>
>> D-->-C-->-B-->-A
>>
>> where letters are components;
>> arrows are the connections among them; and
>> A is the component that finally implements the service interface.
>>
>> Here is my question: How can I compose D, C and B with no services?
>>
>> I know it may sound strange the fact of avoiding service interactions.
>> Actually, I'm interested in both components and services, but I must also
>> know how much iPOJO component model can help me when developing "pure"
>> component applications. I've read in another thread about other OSGi-based
>> component models (Blueprint, DS, Spring-DM, Peaberry), however I don't know
>> them. Please, feel free to report something even it is about other OGSi
>> component models rather than iPOJO.
>>
>
> I am sure Clement can answer about iPOJO details better than I, so I will
> leave it to him, but I believe what you want to do is possible using
> composites.
>
> More generally, it is not clear to me why you see "pure components" as
> being without services...that sounds like object orientation to me.
> Typically, components provide and require interfaces through which they
> interact with other components. In OSGi we treat these interfaces as OSGi
> services (which themselves are just interfaces).
>
> So, even if you are not using OSGi, I would still recommend an approach
> where your components provide and require interfaces, which is the main
> mechanism for keeping component implementations decoupled from each other.
>
> -> richard
>
>
>
>> Thank you in advance,
>>
>>
>> André Lage.
>>
>>
>> ---------------------------------------------------------------------
>> 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]
>
>
