felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raymond Auge <raymond.a...@liferay.com>
Subject Re: [Discuss] Resolver 'latch' bundle / sub module
Date Thu, 10 Nov 2016 16:01:56 GMT
You may want to refresh your memory about this very similar topic discussed
in September of 2014:

https://mail.osgi.org/pipermail/osgi-dev/2014-September/004583.html

- Ray

On Thu, Nov 10, 2016 at 10:45 AM, <davidb@apache.org> wrote:

> Hi all,
>
> I totally agree that using a services-based approach is more elegant here.
>
> However in my use-case the bundles that should wait for the service may not
> be developed with this condition in mind, so it's an extra condition that
> should hold these bundles back. The bundles themselves could be written
> using any technology, maybe with DS, maybe not (simple Bundle Activators).
>
> Maybe my idea isn't so generally useful after all, as services based
> solutions - if you can use them - are certainly better.
>
> I guess I'll hold off contributing this. Thanks all for the feedback.
>
> Cheers,
>
> David
>
> On 10 November 2016 at 15:35, Neil Bartlett <njbartlett@gmail.com> wrote:
>
> >
> > > 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 practice.
> >
> > Neil
> >
> >
> > >
> > > 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
> > >
> >
> >
>



-- 
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
 (@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
 (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message