felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexander Klimetschek (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (FELIX-5410) Web console plugin for troubleshooting wiring issues
Date Tue, 15 Nov 2016 02:42:58 GMT

     [ https://issues.apache.org/jira/browse/FELIX-5410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Alexander Klimetschek updated FELIX-5410:
    Attachment: webconsole-troubleshoot-services.png

Attached a new version that shows referenced, but missing services: [^FELIX-5410-with-services.patch]

Problems/Open points:
* no way to show more information for dynamically registered services, unless system tracks
history of a "good" state and gives hints on where that services might have come from; or
track the unregistering of dynamic services and remember that
* would be great to find out if something is missing because
** it is registered dynamically, but that did not happen
** it is missing a configuration
** other conditions
* component implementation is DS specific, that's why the /system/console/components is in
it's separate module under webconsole-plugins/ds, and why this troubleshooting would need
to live separately as well/or needs to be pluggable (the patch above does it all in the webconsole
project as a demonstration)


> Web console plugin for troubleshooting wiring issues
> ----------------------------------------------------
>                 Key: FELIX-5410
>                 URL: https://issues.apache.org/jira/browse/FELIX-5410
>             Project: Felix
>          Issue Type: New Feature
>          Components: Web Console
>            Reporter: Alexander Klimetschek
>         Attachments: FELIX-5410-with-services.patch, FELIX-5410.patch, webconsole-troubleshoot-services.png,
> h4. Feature
> Add a new view/plugin to the standard webconsole that helps to pin point which bundles,
services or components are the true source for inactive bundles or services.
> * For *bundles* the underlying assumption would be a healthy system with all bundles
active, and thus any inactive can be shown and analyzed as being problematic.
> * For *services/components* one can look at inactive _immediate_ services that fail because
of unsatisfied references. For others, the user might need to enter the "problematic" service
or component they expect to be running to start the analysis.
> h4. Motivation
> In a larger OSGi application with many bundles and components, it can be difficult to
find out the root cause why certain bundles do not start or why a service is not active, especially
for folks new to OSGi or with limited knowledge about the application. I have seen many people
fail, and thus "not like" OSGi because of such hurdles during development, where it is easy
to update on bundle but miss out on crucial dependencies.
> Figuring out is possible through the current web console, but only for experts, if you
click through the bundle or service details. This is usually tedious work, if for example
a lower level bundle is the problem, and 200 others are not active because of it.

This message was sent by Atlassian JIRA

View raw message