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 13:30:53 GMT
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 ?

> >>
> >> 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.

Regards
Felix

> 
> > Regards
> > Felix
> >
> >>
> >>
> >> >
> >> > Regards
> >> > Felix
> >> >
> >> >>
> >> >
> >> >
> >> >
> >>
> >>
> >>
> >
> >
> >
> 
> 
> 



Mime
View raw message