2009/4/13 Clement Escoffier <clement.escoff...@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 issues) > * 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
