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 10:48:49 GMT
Hi,

Am Donnerstag, den 03.02.2011, 11:24 +0100 schrieb Guillaume Nodet: 
> On Thu, Feb 3, 2011 at 10:48, Felix Meschberger <fmeschbe@gmail.com> wrote:
> > Hi,
> >
> > Am Donnerstag, den 03.02.2011, 10:27 +0100 schrieb Guillaume Nodet:
> >> With the multiplicity of extenders, it becomes increasingly difficult
> >> to know when a bundle is actually started.
> >> Another problem is when you actually want to order  bundles starting
> >
> > Are you sure you want to support "order bundles starting" ? I think this
> > is not correct ....
> >
> >> process when they do use extenders.
> >> What would you think about working on a simple API (similar to the
> >> quiesce api) that could be used to have better information and control
> >> over the real state of bundles.
> >> This could also be benefical to applications / subsystems to actually
> >> compute a real state for those.
> >
> > This sounds like the BundleTracker...
> >
> > Or did I miss your goal completely ?
> >
> > BTW: What is "the real state of a bundle" ?
> 
> Yes, I think I haven't explained myself clearly.
> When a bundle is supposed to be extended, this is usually done
> asynchronously by the extender.  For example blueprint does that.
> >From a user point of view, this means that the bundle can actually be
> in an ACTIVE state without being "ready".  The bundle will really be
> "ready" when the blueprint extender will have done its job.  This is
> valid for all extenders that do their job asynchronously.

Declarative Services comes to mind (though this is synchronous).

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 ?

No matter what, it sure depends on the cooperation of the extender,
right ? So for Declarative Services, I could very well imagine, that I
would implement an EventAdmin based solution.

> 
> The problem is that there's currently no easy way to know when you're
> bundle is ready.  The goal would be to be able to give back to the
> user a clear picture of the "state" of everything inside.

By user you mean a system administrator I assume. So yes, I see the
problem.

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

Regards
Felix

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



Mime
View raw message