[DISCUSS] Api for a monitoring real bundles states when used with extenders

[Guillaume Nodet <gn...@gmail.com>]

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

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

Re: [DISCUSS] Api for a monitoring real bundles states when used with extenders

[Achim Nierbeck <bc...@googlemail.com>]

+1 sounds good to me

2011/2/3 Jean-Baptiste Onofré <jb...@nanthrax.net>:
> +1
>
> agree. I think a kind of extenders manager could be helpful. It could track
> the bundle state changes and control the bundles.
>
> Regards
> JB
>
> On 02/03/2011 10:27 AM, Guillaume Nodet wrote:
>>
>> 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
>> 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.
>>
>

Re: [DISCUSS] Api for a monitoring real bundles states when used with extenders

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

+1

agree. I think a kind of extenders manager could be helpful. It could 
track the bundle state changes and control the bundles.

Regards
JB

On 02/03/2011 10:27 AM, Guillaume Nodet wrote:
> 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
> 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.
>

Re: [DISCUSS] Api for a monitoring real bundles states when used with extenders

[Guillaume Nodet <gn...@gmail.com>]

Note that a bundle could be considered ready when it provides a known
service, so I think this information should be captured too.

On Thu, Feb 3, 2011 at 11:24, Guillaume Nodet <gn...@gmail.com> wrote:
> On Thu, Feb 3, 2011 at 10:48, Felix Meschberger <fm...@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.
>
> 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.
>
> 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.
>
>
>>
>> Regards
>> Felix
>>
>>>
>>
>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>



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

Re: [DISCUSS] Api for a monitoring real bundles states when used with extenders

[Felix Meschberger <fm...@gmail.com>]

Hi,

Am Donnerstag, den 03.02.2011, 15:14 +0100 schrieb Guillaume Nodet: 
> On Thu, Feb 3, 2011 at 14:30, Felix Meschberger <fm...@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

Re: [DISCUSS] Api for a monitoring real bundles states when used with extenders

[Guillaume Nodet <gn...@gmail.com>]

On Thu, Feb 3, 2011 at 14:30, Felix Meschberger <fm...@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.
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.

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



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

Re: [DISCUSS] Api for a monitoring real bundles states when used with extenders

[Felix Meschberger <fm...@gmail.com>]

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

Re: [DISCUSS] Api for a monitoring real bundles states when used with extenders

[Guillaume Nodet <gn...@gmail.com>]

On Thu, Feb 3, 2011 at 11:48, Felix Meschberger <fm...@gmail.com> wrote:
> Hi,
>
> Am Donnerstag, den 03.02.2011, 11:24 +0100 schrieb Guillaume Nodet:
>> On Thu, Feb 3, 2011 at 10:48, Felix Meschberger <fm...@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 ?
>

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

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



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

Re: [DISCUSS] Api for a monitoring real bundles states when used with extenders

[Felix Meschberger <fm...@gmail.com>]

Hi,

Am Donnerstag, den 03.02.2011, 11:24 +0100 schrieb Guillaume Nodet: 
> On Thu, Feb 3, 2011 at 10:48, Felix Meschberger <fm...@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
> >
> >>
> >
> >
> >
> 
> 
> 

Re: [DISCUSS] Api for a monitoring real bundles states when used with extenders

[Guillaume Nodet <gn...@gmail.com>]

On Thu, Feb 3, 2011 at 10:48, Felix Meschberger <fm...@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.

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.

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.


>
> Regards
> Felix
>
>>
>
>
>



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

Re: [DISCUSS] Api for a monitoring real bundles states when used with extenders

[Felix Meschberger <fm...@gmail.com>]

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" ?

Regards
Felix

>