On Oct 9, 2013, at 16:57 PM, Christian Schneider <[email protected]> wrote: > On 09.10.2013 15:45, Marcel Offermans wrote: >> On Oct 9, 2013, at 15:15 PM, Christian Schneider <[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.
I'm not convinced that the bundle state should be modified in any way. BundleStateService and BundleState seem to report a (different?) bundle state than the framework would depending on the state of some components in the bundle? I would rather create a separate state model for components and dependencies. That model might point to the bundle that governs the life cycle of such a component but that's all. > 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. So how does he see from the list of bundles that something is wrong? Any bundle that returns "failure" as its state? What if a bundle has two components and one is okay whilst the other is not? For reference, I've seen big applications that had bundles that maintained hundreds of components, each with their own dependencies, state and life cycle. Aggregating all that information to a single "bundle state" just seems wrong. You need to drill down and look at the individual components. > The diagnostics information then shows what exactly is wrong. The second issue you have is that when components don't start up because of missing dependencies, you need tools to find the "root cause". Take an example where you have a lot of bundles, each with one component, and all components depend on a single service. Now assume that service is not available. In your case, all bundles would show a "failure" which would still give you no clue as to what was causing the problems. > 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. I think we can perfectly solve this outside of the framework. Yes it will require some coordination and cooperation between the different DI frameworks, but if enough people think this is worthwhile, we can do this (and define a standard for it). Greetings, Marcel
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
