felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Moloney, Tim M" <Tim.Molo...@ManTech.com>
Subject RE: Google Summer of Code
Date Tue, 09 Jun 2009 14:53:09 GMT
 

On Tuesday, June 09, 2009 03:29, Felix Meschberger
[mailto:fmeschbe@gmail.com] 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.  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.

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?

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

Mime
View raw message