Hi, Am Donnerstag, den 03.02.2011, 15:14 +0100 schrieb Guillaume Nodet: > On Thu, Feb 3, 2011 at 14:30, Felix Meschberger <[email protected]> wrote: > > Hi, > > > > Thanks a lot for your clarifications ! > > > > Am Donnerstag, den 03.02.2011, 13:37 +0100 schrieb Guillaume Nodet: > >> > > >> > But actually, the bundle is ready, when it's started. The services and > >> > components/beans/you-name-it may not available yet at that time, though. > >> > > >> > How about just defining a best practice for such extenders to send an > >> > EventAdmin event once they finished handling a bundle ? > >> > > >> > >> I think all do, but we still don't have any piece of code that grabs > >> and aggregate those for a given bundle. > >> Also, to compute this aggregation, you need to know before-hand what you > >> expect. > > > > So such an extender would still have to "register" itself somehow ? > > I would suppose so, that's why I have the "api" word in the email > thread subject. > One way would be to have extenders registering an osgi service that > could be leveraged by a central service to find the "ready" state of > bundles.
ok. Thinking about it, I'd say then: "give me the API and I add it to Apache Felix DS" ;-) > This may also need (to some degree) cooperation of the bundles so that > they could indicate they need to be extended by a given extender, but > that's a different story I guess. > > > > > >> >> > >> >> As for bundle ordering, I problem I came across is that such > >> >> asynchronous extenders can't be ordered using the start level service, > >> >> and that's sometimes desirable, so I'd like to be able to do that too. > >> > > >> > As always with bundle start ordering: It ain't gonna work. It will work > >> > in a few controlled situations but in general it won't. This is why I > >> > generally try to stop such bundle start order discussions right from the > >> > start ;-) > >> > > >> > Consider for example a simple case of a bundle update: This may happen > >> > at any time where you don't have any influence on ordering anything. > >> > > >> > Another option -- any maybe you mean this -- would be to be able to sort > >> > the call order of the BundleListeners. This could be solved by > >> > supporting whiteboard pattern style registrations for BundleListeners, > >> > which would be called in their service ranking order. Of course this > >> > only works for BundleListeners not registered with the framework > >> > directly.... > >> > >> I am aware of the pitfalls, but I have some very specific use cases > >> which aren't about making things work, but rather making things works > >> nicely. > >> For example consider the two following use cases: > >> * a log bundle is blueprint powered and thus started asycnhronously. > >> All other bundles can actually work without this service being > >> available, but when you start your framework, you'd still like the log > >> bundle to be *ready* before the other ones start to capture most of > >> the log events > >> * you have a bundle which will look for configurations in an > >> external source (for example a jdbc database, or a file directory) and > >> will feed the config admin with such data. When you start the > >> framework, you'd like to avoid having all bundles configured twice, > >> you it would be better if other bundles would wait for that one to be > >> ready before starting. > >> I think such ordering has to be made with the StartLevel service, and > >> once again, I don't want to solve bad designed bundles problems using > >> the start level service, but I think the two uses cases I mentioned > >> are actually valid (well, I do have those problems right now). It > >> would just be better if I could have a better control over a few > >> bundles when the whole thing starts. > > > > Ok. Thanks for enlighten my. > > > > BTW: This is one of the reasons why I created a basically self-contained > > logging support bundle in Sling, which can be started in a plain > > framework and which we do at start level 1. > > Right, in my case, it's not about blueprint, but the logger uses > ConfigAdmin to be configured, so I still need to order things as much > as possible for the very first bundles. I solved this problem by bootstrapping the logger with framework properties (and some fallback) and accept ConfigurationAdmin configuration once ConfigurationAdmin comes in (DynamicImport-Package and ServiceFactory are my friends here). Regards Felix > > > > > Regards > > Felix > > > >> > >> > Regards > >> > Felix > >> > > >> >> > >> >> > >> >> > > >> >> > Regards > >> >> > Felix > >> >> > > >> >> >> > >> >> > > >> >> > > >> >> > > >> >> > >> >> > >> >> > >> > > >> > > >> > > >> > >> > >> > > > > > > > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com
