felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Neil Bartlett <njbartl...@gmail.com>
Subject Re: [Discuss] Resolver 'latch' bundle / sub module
Date Thu, 10 Nov 2016 15:35:46 GMT

> On 10 Nov 2016, at 15:18, Carsten Ziegeler <cziegeler@apache.org> wrote:
> Neil Bartlett wrote
>> I’m also somewhat opposed to David’s approach. I feel that it conflates two separate
concepts: bundles are for packaging and code delivery, this problem space is about enabling/disabling
functionality based on observable conditions.
>> I would prefer to do this with Declarative Services. Rather than “holding back”
an entire bundle, just do it with a DS component using a mandatory @Reference to a service.
When the “external thing” happens, it is detected and mapped to a published service. The
availability of the service allows the component’s @Reference to be satisfied and we are
off to the races. This can also be easily understood and introspected at runtime using the
scr:list and scr:info commands, or the WebConsole with X-Ray.
> While the service approach is definitely working and a nice way as it is
> already available, I see a scalability problem.
> Think about use cases similar to the extender mechanism, you don't want
> that your bundle starts until the DS extender is available. But you
> don't want that each and every service has a reference to the DS runtime
> service.

Why don’t I want my bundle to start until the DS extender is available? It makes no difference.

> Let's assume you have an app, consisting of dozens of services, for
> simplicity let's assume they are all in one bundle. Now you don't want
> to start any of these services until some condition is met.
> Clearly, you can add these special reference to each and every of the
> dozen services, but that doesn't look nice to me.

I don’t think it would work out that way in practice. Whatever this external condition is,
would there really be dozens of components that refer to it *directly*? I think it’s more
likely that a small number of low-level components would use that condition directly and offer
services that are consumed by higher-level components. Thus the lifecycle of the higher-level
components would still be contingent on the external condition, but indirectly.

> Then there is the problem if someone does not want to use DS (ok that's
> their own problem maybe), or there is a bundle activator or something.
> In general, you simply don't want to start the app bundle at all.

Then it seems we are talking past each other. I thought we were trying to find a good pattern
for implementing this scenario, where functionality must be temporally dependent on an external
condition. I still think this is best done in DS… but of course would be quite simple in
Blueprint or DependencyManager or iPOJO, etc. Or even with the low-level APIs and ServiceTracker,
if you happen to be a masochist.

On the other hand you seem to be talking about poorly designed bundles that make assumptions
about external conditions — and finding workarounds to allow those bundles to still work
when the assumptions are invalidated. If so then David’s proposal is valuable in that context.

My problem is that in OSGi we are constantly fighting against bad practices and preconceptions.
For example, every newbie always asks how to achieve start ordering with the StartLevel service.
We could just tell them how to do it, or we can give them the understanding and techniques
so that start ordering becomes a non-issue. David’s proposal is a bit like Start Levels:
I’m not saying it’s never necessary, but I wouldn’t want it to be misconstrued as good


> Requirements and capabilities are a great mechanism for this, but you
> can't dynamically add capabilities.
> Carsten
> -- 
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org

View raw message