Hi, Am Montag, den 07.02.2011, 19:16 +0000 schrieb Alasdair Nottingham: > 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.
Interesting, we have been discussing this in the Sling context, too. I am not really convinced about the ability to implement such a thing. > 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) >From the POV of DS there is no need, because DS works synchronously, i.e. by the time the asynchronous bundle STARTED events are fired, all components have been processed and activated (as far as possible). As I understand Guillaume, his patch does a similar thing for blueprint. This means, when the STARTLEVEL_CHANGED (or FRAMEWORK_STARTED) event is fired, DS (and after ARIES-536 Blueprint) processing has completed. This does not mean, all components are active -- there may still be problems; that's where a "start completed" thingy would come in ... Regard Felix > > 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 > > > > >
