Felix, You're right about the dependencies obviously: the plugin bundle would need to depend on the JAXRS API but the web console itself would depend on the API and some implementation like Jersey. That would be the biggest disadvantage in my mind, because at this point in time the felix web console is a very lightweight solution that doesn't need any dependencies.
On the other hand, this solution would give us some benefits as well. The JAXRS bean I mentioned is just a POJO with methods and annotations. This will map the methods to URIs, allowing us to easily provide multiple uris from a single plugin. So we can have methods there for serving the main page content but others could handle POSTs or serve JSON or XML. As for rendering the reponse, you can still do that using a plain PrintWriter as we do in the Servlets now if we want a lightweight plugin, but it would also become possible use another kind of view technology (e.g. JSP or Lift templates) if people prefer that or to serve other kinds of resources (images, css style sheets, ...) Regards, Gert Vanthienen ------------------------ Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/6/9 Felix Meschberger <fmesc...@gmail.com>: > Hi, > > Gert Vanthienen schrieb: >> L.S., >> >> How about adding support for using JAX-RS resource beans for extending >> the felix web console? So instead of registering a servlet, you can >> register a JAX-RS bean. One of the methods on the bean can be used to >> render the 'main' contents of the web console plugin page, but you can >> also add other methods and annotate them with GET/POST for providing >> JSON resources or handling form submits. >> >> This will also remove the dependency on the felix web console bundle >> for the extension bundle while making it easier to implement multiple >> uris/actions without having to override the doGet/doPost methods and >> allow us to use some other template engine/language (JSP, Lift, ...) >> in the extension bundle without the need for the felix web console to >> be aware of those. >> >> The only real drawback I see is the fact that the Felix Web Console >> bundle itself would get another dependency, it would need the JAX-RS >> API. >> >> Wdyt? > > What else would be required ? > Wouldn't we need an implementation of the API to glue this all together? > What do you mean by "register a JAX-RS bean" ? > > IMHO registering a javax.servlet.Service is very appropriate in the OSGi > context. > > Regards > Felix > >> >> Gert Vanthienen >> ------------------------ >> Open Source SOA: http://fusesource.com >> Blog: http://gertvanthienen.blogspot.com/ >> >> >> >> 2009/6/9 Felix Meschberger <fmesc...@gmail.com>: >>> 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 >>>>> >> >
