On 09.10.2013 15:45, Marcel Offermans wrote:
On Oct 9, 2013, at 15:15 PM, Christian Schneider
<[email protected] <mailto:[email protected]>> wrote:
You are right. The resolver is probably the wrong place to put this.
Anyway if I understood it correctly then the resolver is involved
when the bundle goes into status resolved. So as I am interested in
the transition from resolved to active the resolver is probably the
wrong place.
I don't understand why you would want to change the bundle life cycle
at all. We are talking about something completely different here:
diagnosing the state of components inside bundles. Each of these
components has a life cycle of their own. That's what these
diagnostics should be about.
As one of its authors, the Apache Felix Dependency Manager already has
diagnostics, which are available via a shell command and I think some
of the others do as well. It would be interesting to compare those
implementations to see if they are similar enough to try and
standardize them.
Thanks for the pointer. I will take a look at the Dependency Manager to
see how it does diagnostics.
For the karaf implementation you may take a look at:
http://svn.apache.org/repos/asf/karaf/trunk/bundle/core/src/main/java/org/apache/karaf/bundle/core/BundleStateService.java
http://svn.apache.org/repos/asf/karaf/trunk/bundle/core/src/main/java/org/apache/karaf/bundle/core/internal/BlueprintListener.java
http://svn.apache.org/repos/asf/karaf/trunk/bundle/springstate/src/main/java/org/apache/karaf/bundle/springstate/SpringApplicationListener.java
http://svn.apache.org/repos/asf/karaf/trunk/bundle/command/src/main/java/org/apache/karaf/bundle/command/ListBundles.java
http://svn.apache.org/repos/asf/karaf/trunk/bundle/core/src/main/java/org/apache/karaf/bundle/core/internal/BundleServiceImpl.java
I am not sure if the design is really optimal. Basically we provide a
BundleStateService with the bundle state from the framework point of
view and some textual diagnostics.
In the ListBundles command we use the combined state from BundleService
to show an extended state that combines the OSGi bundle status with the
state from the StateServices. So an admin can look at the list of
bundles and directly see if something is wrong.
The diagnostics information then shows what exactly is wrong.
The bad thing is that we need to write a StateService for each framework
out there and maybe even several impls if the framework changes over
time. A standardized aproach would allow the framework to implement the
standard and we could just query the status.
Best regards,
Christian
--
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
