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. Alasdair On 3 February 2011 15:43, Guillaume Nodet <[email protected]> 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 <[email protected]> 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: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com > -- Alasdair Nottingham [email protected]
