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 ? > >> > >> 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. Regards Felix > > > Regards > > Felix > > > >> > >> > >> > > >> > Regards > >> > Felix > >> > > >> >> > >> > > >> > > >> > > >> > >> > >> > > > > > > > > >
