felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Neil Bartlett <njbartl...@gmail.com>
Subject Re: DependencyManager and bundle-private components
Date Thu, 21 May 2015 15:28:15 GMT
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.


> On 21 May 2015, at 15:52, Simon Kitching <simon@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-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org

To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

View raw message