II've been through this too, on a moderately complex project using DS. At first we had a lot of problems with components starting up and nobody knowing why, and we wished for better diagnostics from the framework / the SCR / the console / wherever. As the project progressed we got much better at figuring stuff out and the need became less urgent, but the kind of analyses we made could certainly be automated to improve productivity. If all implementations of DS would make this diagnostic information available through the same API this would favour the development of tools which could be used on all implementations. As usual the rule is "agree on the interface, compete on the implementation".
Whilst it is reasonable to expect that all DS implementations are sufficiently similar that they can all report their internal state in a uniform way, I don't think the same can be said of all DI frameworks, still less all extenders. If all DI frameworks were so similar, we might as well just dump the others and use DS. ;-) The third-party module issue is a real one, and means that you can end up with two or three DI frameworks co-existing which is a Real Pain. Maybe there is a place for a tool which would allow a module to be published in multiple DI "flavours" at the push of a button? I don't think the bundle states are really confusing once you know what they mean. Changing or renaming them would create far more confusion (and you can't change the underlying state diagram without causing massive breakage). In all I see more opportunities for tool-builders here than a need for new specifications. Regards Chris > Hi Peter, > > sounds interesting. I will take a look at the scr diagnostics too. > > Yes it would be nice to have a common store of problems. Even if you > primarily use one technology like SCR chances are high that you include > some third party module which uses one of the other solutions. So a > common place to find the status of a bundle and the reasons for failures > would be great. > > The question is of course how a reliable method of collecting and > querying the problems might look like. The current aproach we used in > karaf to catch events is not very reliable as it requires that we > register very early to not loose events. So perhaps a better model would > be that the DI frameworks offer a diagnostic service where you can ask > about a bundle. > > I understand that touching the bundle state is something that should not > be done without compelling reasons. The problem though is that the > bundle state currently is not very helpful when you look at the RESOLVED > and ACTIVE states. > > Let's look at these states: > ACTIVE: This says the bundle activator has been run or that no bundle > activator was found. > When using one of the extender frameworks this state is meaningless as > the bundle may still have failed. > > RESOLVED: This either says that the bundle was never meant to be started > or has failed to start. So especially in Eclipse RCP where not all > bundles are started by default this state alone is also meaningless > regarding initialization. > > I think it would help a lot if the ACTIVE state was redefined to > something like the bundle initialization was successfull. Bundle > initialialization is successful if all initilization methods were > successful. So this would be activator + all framework based > initializations. Of course this requires that the OSGI framework knows > which frameworks are expected to work on the bundle. I think the current > model of having very loosely coupled extenders is not so good as the > framework has no means to determine if a bundle is really up. > > The second thing is that it would be great to distinguish between > bundles that are not expected to be started and bundles that failed to > start. So some kind of failed state would be nice. > > A third thing is if a bundle is not fully up because it waits for e.g. a > blueprint namespace provider or for other services. In the case of > static dependencies I think this can be solved using capabilties. So > this is probably no big issue. > > So this might be a reason to think about the OSGI bundle lifecycle. Of > course this is nothing that should or can be implemented in short term > but we should not simply discard the idea of touching the bundle > lifecycle. > > Best regards > > Christian > > > On 09.10.2013 19:03, Peter Kriens wrote: >> Reading this discussion it seems that what is needed is very much what >> is provided by the SCR diagnostics service? If I go to the webconsole >> in Apache Felix I can see why a component is not active. Is this not >> the template we're looking for? I use it extensively in Xray and it >> works very nice. So of course the easy solution is just to use DS and >> use the diagnostic API provided by Apache Felix (I think it is also >> implemented in Equinox now)? :-) >> >> Since there are other extenders, it seems to make sense to provide a >> registry of 'issues', where extenders can report a problem on a >> component, a likely cause, and maybe an advice to repair it. >> >> I do agree with Richard, BJ, and Marcel. This is NOT a framework >> issue, and the Bundle state should be left alone. This is another level. >> >> Kind regards, >> >> Peter Kriens >> >> >> > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
