Hi, Moloney, Tim M schrieb: > I quickly discovered that things are not what they appeared. I didn't > investigate how the core plugins are loaded but the features plugin > appears to be loaded via Spring. Loading plugins this way doesn't use > AbstractWebConsolePlugin as it is "advertised" and many things just > don't work (activate() and deactivate() are never called, > getBundleContext() returns null, etc). It looks like a lot of the > webconsole infrastructure is hidden in > org.apache.felix.webconsole.internal so to get a plugin working with any > reasonable functionality would require duplicating a lot of those > classes.
That *is* a problem currently -- and lacking documentation on how to extend the web console. Currently you have to basically extend the AbstractWebConsolePlugin abstract class and implement the renderContent, getLabel, and getTitle methods. This method is called to render the "inner contents" of a page. The navigation, header and footer are rendered by the AbstractWebConsolePlugin itself. The class you so created must be registered as a OSGi service with the interface javax.servlet.Servlet. For the web console to pick up this Servlet service as service property named "felix.webconsole.label" must be set to a single, non-empty string providing the URL path segment of the plugin page. That's all. If you want to handle updates (POST requests, that is), you implement the doPost method. You may also overwrite the doGet method if you want to add to or replace the standard GET method handling. Plugin Initialization: You have to initialize the plugin yourself by calling the activate(BundleContext) method before registering the plugin as a service. At the end you should call the deactivate() method to cleanup the plugin. For example, if you use Declarative services just call the activate(BundleContext) from your component's activate(ComponentContext) method and likewise the deactivate from the component's deactivate(ComponentContext) method. This way of extending the console is not super-great (though it works great once you get around the corners). For instance it creates a dependency on the Web Console bundle importing the o.a.f.webconsole package. Also the initialization is not properly defined. So I am thinking along the lines of supporting plain servlets (anyhting implementing javax.servlet.Servlet) and providing easier integraiton points. I am going to update the web console documentation page [1] with some more information here .... > > Perhaps I missed the proper way to initialize a webconsole plugin and > get at the utility methods. If not, I would suggest refactoring the > infrastructure of webconsole so that extending AbstractWebConsolePlugin > does work as expected. How do you define "work as expected" ? Regards Felix [1] http://felix.apache.org/site/apache-felix-web-console.html > > > Tim Moloney The reasonable man adapts himself to > MRSL the world; the unreasonable one persists > 2015 Cattlemen Road in trying to adapt the world to himself. > Sarasota, FL 34232 Therefore all progress depends on the > (941) 377-6775 x208 unreasonable man. George Bernard Shaw > > > >> -----Original Message----- >> From: Marcin Wilkos [mailto:marcin.wil...@gmail.com] >> Sent: Monday, June 08, 2009 17:32 >> To: dev@felix.apache.org >> Subject: Google Summer of Code >> >> Hi, >> I'm Marcin Wilkos. Like Gert Vanthienen wrote before I'm working on >> webconsole for Karaf and ServiceMix as GSoC project. I'll be >> sending weekly >> reports to this list. >> In last week I focused on first extension for felix web >> console, which lists >> Karaf features. I created JIRA issue for this and uploaded a >> patch. Gert >> checked it and uploaded to svn. >> Regards, >> Marcin Wilkos >> >
