Hi Simon, You’re essentially correct, at least in the difference between Blueprint and DS. I can’t comment on DM since I don’t use it. However the wording of your email implies that this is a failing of DS and a win for Blueprint, whereas I tend to see it as the exact opposite!
For me, Blueprint does not successfully hide the OSGi lifecycle but adds an additional lifecycle within the OSGi one. For example, Blueprint containers cannot be activated until all of the mandatory references within the container are satisfied… but there can be beans in the container that are fully satisfied because they do not need the unsatisfied references. Why not start just those beans? It doesn’t make sense. Still, if that is the Blueprint policy then you would at least expect it to be consistent, so that when a mandatory reference from an active container becomes unsatisfied, the container will be deactivated. But Blueprint doesn’t actually do this, it merely puts the container into a kind of suspended state. Again it doesn’t make sense. Well actually it makes sense when you realise that Blueprint represents a legacy container concept that has been crowbarred to fit into OSGi… Regarding your last point; you are right that components (beans if you prefer) often need to use other objects from within the bundle, and those objects should not escape from the bundle. In DS I find it perfectly acceptable to instantiate these components with the “new” keyword. I don’t really see why I would want to use a type-unsafe XML descriptor to do this rather than Java code. Regards, Neil > On 21 May 2015, at 15:52, Simon Kitching <si...@vonos.net> wrote: > > Hi, > > In blueprint it is possible to define arbitrary objects (beans) which are not > published to the service registry but nevertheless can be injected into other > beans. > > AFAICT, in both declarative-services and felix-dm, the only objects that can > be injected are references to services from the OSGi registry. Is this > correct? > > I understand that with DS and DM, components follow the standard OSGi > lifecycles, in contrast to the Blueprint approach of "hiding" the lifecycle. > In particular, in DS and DM when a component's mandatory dependency is > deregistered then the component is also deregistered (which can cascade > further). And the kind of tracking of dependencies required to make this > happen is exactly what a service registry does. > > However it's common for a bundle to have objects which are purely internal > implementation details of the bundle, and are not for external use. Yet as > far as I can see, in order to manage them with DS or DM, such internal > objects need to be published into the global service registry - just to be > able to then inject them back into components in the same bundle. > > Have I misunderstood something? > > Thanks, > Simon > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
