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
