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. 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. > > Regards > Felix > >> >> > Regards >> > Felix >> > >> >> >> >> >> >> > >> >> > Regards >> >> > Felix >> >> > >> >> >> >> >> > >> >> > >> >> > >> >> >> >> >> >> >> > >> > >> > >> >> >> > > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
