Hi, Moloney, Tim M schrieb: > > > On Tuesday, June 09, 2009 03:29, Felix Meschberger > [mailto:[email protected]] wrote: > >> 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 .... > > Great information. Now that I'm better informed, I'll give it another > go. > >>> 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" ? > > Granted, I made some assumptions. Most of the time when you implement > an interface or extend an abstract class that is part of a plugin > system, especially ones with method names like init() and activate(), > you register the object and the plugin system initializes the object by > calling the init() or activate() method.
Yes, true. This may be part of the history and evolvment of the plugin API. And I fully agree, that without any JavaDoc at all, this is hard to understand and grock !! > I see that the feature plugin > didn't do that in the Java code so I assumed that whatever code found > and loaded the feature plugin would also call activate(). With the > information you provided above, I see that Spring is registering the > service but is it calling activate()? I don't know Spring. I don't know (yet) how the plugin is done, I will have a look at it and try to see, what is going on. > > How would I register a URL other than the plugin page? For example, the > bundles plugin has bundles.js and several images. Is there a convenient > way to register URLs for a plugin or do I just register them with the > HttpService myself? This is registering resources. It is listed as one of the open issues with respect to the console extensibility. For the Web Console itself we register a resource location with the HttpService. For plugins, I think this is not appropriate. Rather there should probably be a mechanism to provide the resource such that the Web Console can grab it much like we do for plugin servlets. One idea I had was listing the resource paths (or locations) in the bundle manifest and the Web Console would pick these up and delegate appropriately. Regards Felix > > Thanks for the missing information. > >> 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 >
