aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <>
Subject Re: [DISCUSS] Api for a monitoring real bundles states when used with extenders
Date Thu, 03 Feb 2011 12:37:23 GMT
On Thu, Feb 3, 2011 at 11:48, Felix Meschberger <> wrote:
> Hi,
> Am Donnerstag, den 03.02.2011, 11:24 +0100 schrieb Guillaume Nodet:
>> On Thu, Feb 3, 2011 at 10:48, Felix Meschberger <> 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 ?

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.

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

Right, that's the kind of people this would target.

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

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

Guillaume Nodet
Open Source SOA

View raw message