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
