felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@gmail.com>
Subject Re: Google Summer of Code
Date Tue, 09 Jun 2009 17:48:34 GMT
Hi,

Moloney, Tim M schrieb:
>  
> 
> 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.

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
> 

Mime
View raw message