I think we can use the req ad caps of bundles to give some hints about root causes .. these are quite coarse though. So for example you can only find a bundle that exports a service. If you then follow all services it imports you get a lot of false positives. You will also not find missing configs as a cause.
For DS we have a lot more possibilities. As we can introspect the components we can see what services they publish and consume and also if they need a config to become active. So I think it makes a lot of sense to have a special analysis for DS and this might be true for other technologies too. Christian Am Mo., 20. Aug. 2018 um 15:53 Uhr schrieb Raymond Auge < [email protected]>: > Granted, I think the basic platform here is osgi.service req&cap vs runtime > anyway. That's the ideal everything should aspire to. No plugins required. > > - Ray > > On Mon, Aug 20, 2018 at 9:34 AM, Neil Bartlett <[email protected]> > wrote: > > > I agree with the principle of making the diagnostics generic and > > extensible. It needs to be done carefully though. Imagine a scenario > where > > the diagnostic tool is not working because of a missing plugin or config, > > and you can't figure out why... > > > > Neil > > > > On Mon, Aug 20, 2018 at 2:31 PM Christian Schneider < > > [email protected]> > > wrote: > > > > > Yes .. I fully agree about a more general system. > > > Maybe similar to the diag command in karaf where we provide plugins for > > the > > > different technologies. > > > > > > I propose to start with what we have in systemready and then move to a > > more > > > generic architecture over time. > > > > > > Christian > > > > > > > > > Am Mo., 20. Aug. 2018 um 15:14 Uhr schrieb Raymond Auge < > > > [email protected]>: > > > > > > > Something to consider is if this system could be adaptable so that > it's > > > not > > > > strictly limited or tied to DS. It would be nice to be able to add > > > support > > > > for CDI, and perhaps various whiteboards (i.e. http, jaxrs). > > > > > > > > Sincerely, > > > > - Ray > > > > > > > > On Mon, Aug 20, 2018 at 9:10 AM, Karl Pauls <[email protected]> > > wrote: > > > > > > > > > I don't see why not :-) > > > > > > > > > > regards, > > > > > > > > > > Karl > > > > > On Mon, Aug 20, 2018 at 3:09 PM Christian Schneider > > > > > <[email protected]> wrote: > > > > > > > > > > > > I just talked with Neil and Todor on the OSGi slack about the > need > > > for > > > > a > > > > > > root cause analysis tool for DS and OSGi in general. > > > > > > We have this inside systemready but it seems like a good idea to > > have > > > > > root > > > > > > cause analysis as an extra bundle so it can also be used in cases > > > where > > > > > > systemready does not make sense. > > > > > > > > > > > > So I propose to create a new project that just takes care of root > > > cause > > > > > > analysis. > > > > > > For reference: This is the current root cause code. > > > > > > https://github.com/apache/felix/tree/trunk/systemready/ > > > > > src/main/java/org/apache/felix/systemready/rootcause > > > > > > > > > > > > WDYT? > > > > > > > > > > > > Christian > > > > > > > > > > > > -- > > > > > > -- > > > > > > Christian Schneider > > > > > > http://www.liquid-reality.de > > > > > > > > > > > > Computer Scientist > > > > > > http://www.adobe.com > > > > > > > > > > > > > > > > > > > > -- > > > > > Karl Pauls > > > > > [email protected] > > > > > > > > > > > > > > > > > > > > > -- > > > > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > > > > (@rotty3000) > > > > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> > > > > (@Liferay) > > > > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> > > > > (@OSGiAlliance) > > > > > > > > > > > > > -- > > > -- > > > Christian Schneider > > > http://www.liquid-reality.de > > > > > > Computer Scientist > > > http://www.adobe.com > > > > > > > > > -- > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > (@rotty3000) > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> > (@Liferay) > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> > (@OSGiAlliance) > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
