Page History

...

The Web Console can be extended by registering an OSGi service for the interface javax.servlet.Servlet with the service property felix.webconsole.label set to the label (last segment in the URL) of the page. The respective service is called a Web Console Plugin or a plugin for short.

The AbstractWebConsolePlugin

To leverage the rendering of the common header and footer around the plugin's data area, the plugin must extend the abstract org.apache.felix.webconsole.AbstractWebConsolePlugin class implementing the following methods:

• renderContext(HttpServletRequest, HttpServletResponse) – This method is called to render the actual plugin data area.
• getLabel() – Returns the last path segment of the plugin page. This should return the value to which the felix.webconsole.label service registration propery is set.
• getTitle() – Returns a human readable title to be displayed at the top of the plugin page.

To fully leverage the AbstractWebConsolePlugin it must be initialiazed before registering the extension as a service. Likewise after unregistering the service, the plugin should be destroyed. To this avail the following methods are provided in the AbstractWebConsolePlugin:

• activateBundle(BundleContext) – Initializes the plugin with the BundleContext and prepares some data to be rendered in the header and footer areas.
• deactivate() – Destroys the plugin.

In addition to these OSGi-oriented setup methods the Web Console itself will call the Servlet.init(ServletConfig) method before putting the plugin into service and the Servlet.destroy() method when the plugin is removed.

Helper

Before calling the plugin the Web Console sets the org.apache.felix.webconsole.internal.servlet.OsgiManager.appRoot request attribute to the root path of the web console consisting of the servlet context path (HttpServletRequest.getContextPath()) and the servlet path of the web console (HttpServletRequest.getServletPath()). This request attribute may be used by plugins to render absolute links is very simple but it creates a wire from the plugin bundle to the Web Console bundle, which may not be desired. One reason is that updating the web console may cause the plugin bundle to be refreshed, which does not make any sense from an application point of view). For this reason, we are currently investigating how to support plugins with header and footer rendering without requiring to extend the AbstractWebConsolePlugin class.Such plugins, will be able to access information from the AbstractWebConsolePlugin which is now available to extensions of that class through method calls.

Further issues with respect to extensions

...

• It is currently not yet resolved how to add resources in plugins.
• Many requirements exist to be able to customize some areas of look and feel of the console; most notably the logo and vendor links.

...