aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@gmail.com>
Subject Re: [DISCUSS] Api for a monitoring real bundles states when used with extenders
Date Thu, 03 Feb 2011 14:28:31 GMT
Hi,

Am Donnerstag, den 03.02.2011, 15:14 +0100 schrieb Guillaume Nodet: 
> On Thu, Feb 3, 2011 at 14:30, Felix Meschberger <fmeschbe@gmail.com> wrote:
> > Hi,
> >
> > Thanks a lot for your clarifications !
> >
> > Am Donnerstag, den 03.02.2011, 13:37 +0100 schrieb Guillaume Nodet:
> >> >
> >> > But actually, the bundle is ready, when it's started. The services and
> >> > components/beans/you-name-it may not available yet at that time, though.
> >> >
> >> > How about just defining a best practice for such extenders to send an
> >> > EventAdmin event once they finished handling a bundle ?
> >> >
> >>
> >> I think all do, but we still don't have any piece of code that grabs
> >> and aggregate those for a given bundle.
> >> Also, to compute this aggregation, you need to know before-hand what you expect.
> >
> > So such an extender would still have to "register" itself somehow ?
> 
> I would suppose so, that's why I have the "api" word in the email
> thread subject.
> One way would be to have extenders registering an osgi service that
> could be leveraged by a central service to find the "ready" state of
> bundles.

ok.

Thinking about it, I'd say then: "give me the API and I add it to Apache
Felix DS" ;-)

> This may also need (to some degree) cooperation of the bundles so that
> they could indicate they need to be extended by a given extender, but
> that's a different story I guess.
> 
> 
> >
> >> >>
> >> >> As for bundle ordering, I problem I came across is that such
> >> >> asynchronous extenders can't be ordered using the start level service,
> >> >> and that's sometimes desirable, so I'd like to be able to do that too.
> >> >
> >> > As always with bundle start ordering: It ain't gonna work. It will work
> >> > in a few controlled situations but in general it won't. This is why I
> >> > generally try to stop such bundle start order discussions right from the
> >> > start ;-)
> >> >
> >> > Consider for example a simple case of a bundle update: This may happen
> >> > at any time where you don't have any influence on ordering anything.
> >> >
> >> > Another option -- any maybe you mean this -- would be to be able to sort
> >> > the call order of the BundleListeners. This could be solved by
> >> > supporting whiteboard pattern style registrations for BundleListeners,
> >> > which would be called in their service ranking order. Of course this
> >> > only works for BundleListeners not registered with the framework
> >> > directly....
> >>
> >> I am aware of the pitfalls, but I have some very specific use cases
> >> which aren't about making things work, but rather making things works
> >> nicely.
> >> For example consider the two following use cases:
> >>   * a log bundle is blueprint powered and thus started asycnhronously.
> >> All other bundles can actually work without this service being
> >> available, but when you start your framework, you'd still like the log
> >> bundle to be *ready* before the other ones start to capture most of
> >> the log events
> >>   * you have a bundle which will look for configurations in an
> >> external source (for example a jdbc database, or a file directory) and
> >> will feed the config admin with such data.  When you start the
> >> framework, you'd like to avoid having all bundles configured twice,
> >> you it would be better if other bundles would wait for that one to be
> >> ready before starting.
> >> I think such ordering has to be made with the StartLevel service, and
> >> once again, I don't want to solve bad designed bundles problems using
> >> the start level service, but I think the two uses cases I mentioned
> >> are actually valid (well, I do have those problems right now).  It
> >> would just be better if I could have a better control over a few
> >> bundles when the whole thing starts.
> >
> > Ok. Thanks for enlighten my.
> >
> > BTW: This is one of the reasons why I created a basically self-contained
> > logging support bundle in Sling, which can be started in a plain
> > framework and which we do at start level 1.
> 
> Right, in my case, it's not about blueprint, but the logger uses
> ConfigAdmin to be configured, so I still need to order things as much
> as possible for the very first bundles.

I solved this problem by bootstrapping the logger with framework
properties (and some fallback) and accept ConfigurationAdmin
configuration once ConfigurationAdmin comes in (DynamicImport-Package
and ServiceFactory are my friends here).

Regards
Felix


> 
> >
> > Regards
> > Felix
> >
> >>
> >> > Regards
> >> > Felix
> >> >
> >> >>
> >> >>
> >> >> >
> >> >> > Regards
> >> >> > Felix
> >> >> >
> >> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >
> >> >
> >> >
> >>
> >>
> >>
> >
> >
> >
> 
> 
> 
> -- 
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com



Mime
View raw message