felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart McCulloch <mccu...@gmail.com>
Subject Re: iPojo and Blueprint services
Date Mon, 13 Apr 2009 08:33:04 GMT
2009/4/13 Clement Escoffier <clement.escoffier@gmail.com>

> Hi !
> On 12.04.2009, at 22:06, Guillaume Nodet wrote:
>  I'm investigating implementing the blueprint spec on top of iPojo, but
>> after digging a bit in the iPojo code, I have a few questions.
> Nice investigation ;-)
>>  * constructor injection seems to be missing
> True, I' m not a fan of constructor injection. However, if it's a "must", I
> will add it.
> Service will be injected by using temporal dependencies (with or without
> proxies).

I think constructor injection would be a "nice-to-have" because I do know
several people who aren't fans of setter injection (due to mutability

>  * not sure how to inject other components as properties of a given
>> component.  It seems properties can only handle simple types, while
>> dependencies require interfaces
> About properties : primitives and objects are supported, as well as lists,
> dictionaries and maps of objects. To inject an object, either you create the
> object and add it to the instance configuration (so, must use the iPOJO
> api), or you have a type with a String constructor (in this case, the
> property can be declared in the metadata.xml file).
> So, you can inject instance with properties. But, properties are not
> intended to impact the lifecycle. However, when you inject an instance, and
> if this instance is invalid, the instance using the invalid instance should
> be invalid too.
> About services: I recently remove the 'interface' limitation. This is
> available is the trunk version (and so will be available in the 1.4.0
> version).
>>  * ability to create and populate collections to inject as properties
>> (only collections of simple types are supported afaik)
> List, vector, map and dictionary of any type (as well as maps of lists of
> dictionaries of vectors) are supported.
>  * ability to expose classes and not only interfaces in the osgi registry
> As said above, this was recently fixed.
>>  * when manipulating the bytecode to enhance the classes, can iPojo
>> handle the parent classes ? i.e. if a field is defined in the parent
>> class, will iPojo manipulate it accordingly ?
> That's more tricky. iPOJO does not manipulate parent class. The issue is
> that 1) parent classes can be in a different bundle (not iPOJO powered), and
> the parent class can be extended by non iPOJO classes. So, right now, only
> method injection is supported in parent classes. I plan to try to support
> parent manipulation, it's on the roadmap since at least one year and never
> find an adequate time slot).

just wondering... does this mean you should be careful when exporting
packages containing iPOJO powered classes (or perhaps you shouldn't
export them at all, just to be safe?)

>  On point #2, i think iPojo can only handle dependencies that are
>> imported as OSGi services.  If this is true, does this mean I have to
>> create a composite so that all component instances are create at the
>> composite level and not really exported in the OSGi registry ?
> I would prefer that way:
> - first instance injection can impact the lifecycle. Service injection
> impacts the lifecyle, so makes sense to use to inject instances.
> - composite brings the isolation property that is also promoted by the
> blueprint. Only beans of the same application context can be injected. In
> iPOJO terms, it would be : services from the same composite (i.e. service
> context) can be injected.
>> The blueprint spec mostly rely on component dependency injection where
>> components are instanciated and wired explicitely.  How can I achieve
>> that using iPojo ?
> Inside composites, it's possible. Instances are declared with:
> <composite>
> <instance .../>
> ...
> </composite>
> I will commit the API allowing to declare composites "programmatically".
> If you rely on the composite service registry to bound instances together,
> you can provide all the Blueprint features.
> Regards,
> Clement
>  --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
Cheers, Stuart

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message