aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alasdair Nottingham <>
Subject Re: [DISCUSS] ARIES-536
Date Mon, 07 Feb 2011 19:16:57 GMT
I'm not sure but I get the feeling there are potentially two things here:

1. A ready service, something which I believe has been talked about in
the OSGi alliance. I can see a use for something like this, but I'd
like to see a proposal. I think there are many complexities involved,
like how do you make it work and not require it to be omniscient.
2. A smart start level service that waits for blueprint/DS type things
to be done at one start level before progression to the next. This
needs 1)

As I said I can see value in 1, 2 is something you could probably put
in any management agent for OSGi, so putting it start level seems odd
to me.


On 3 February 2011 15:43, Guillaume Nodet <> wrote:
> That's exactly what it's about.  Thx for casting your own lights on that.
> On Thu, Feb 3, 2011 at 16:40, Felix Meschberger <> wrote:
>> Hi,
>> Am Donnerstag, den 03.02.2011, 16:29 +0100 schrieb Guillaume Nodet:
>>> I've committed a patch for ARIES-536 which I'm sure some people will
>>> disagree with.
>>> However:
>>>   * I don't see anything in the blueprint spec that forbids such a behavior
>>>   * this isn't enabled by default
>>>   * that's how DS works so I don't think it's against OSGi best
>>> practices or anything like that
>> IIUIC this is about whether to run blueprint support for a bundle
>> synchronous upon the Bundle.STARTED event or asynchronously on another
>> thread sometime later. Right ?
>> From my experience with the Apache Felix Declarative Services
>> implementation: I used to start declared component asynchronously
>> getting all sorts of issues -- mostly the FRAMEWORK_STARTED event being
>> fired long before all components have been handled.
>> So, after some discussion with the maintainer of the Equinox
>> implementation (they already did synchronous processing at that time), I
>> switched to synchronous processing, too.
>> And from what I can tell, this helped tremendously .. For example system
>> startup is in fact shorter (interestingly) but more importantly, DS
>> processing is complete once the FRAMEWORK_STARTED event is fired.
>> So I would think, this would be a valuable to change (not knowing any
>> internals).
>> Regards
>> Felix
>>> I certainly don't want to start a flame war, but I don't want to
>>> sneakily push that into the codebase either ;-)
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog:
> ------------------------
> Open Source SOA

Alasdair Nottingham

View raw message