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).
* 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).
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
