I've actually started a different thread about that, see http://mail-archives.apache.org/mod_mbox/aries-dev/201102.mbox/%[email protected]%3E I thought you were mostly referring to that discussion, but I may have misunderstood.
On Mon, Feb 7, 2011 at 20:26, Guillaume Nodet <[email protected]> wrote: > On Mon, Feb 7, 2011 at 20:16, Alasdair Nottingham <[email protected]> wrote: >> 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. > > Yes, and I think Aries could be a good location to prototype such a > thing. IIRC it has been removed from subsystem discussions so I guess > the OSGi EEG is not really willing to work on that much. > >> 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. >> > > Well, except that if you don't define an API for #2, the start level > service needs to be aware of all the extenders that can be deployed. > This knowledge on itself doesn't really scale and you may need to > end-up dynamically importing tons of packages to actually access the > data from those providers (what about importing different versions ?). > Not sure how that would work. > >> 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] >> > > > > -- > 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
