Hi Gert Gert Vanthienen schrieb: > 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.
That is exactly one of my biggest issues ... In addition it would "lock" the console into a single presentation technology. There are others like JSF, Apache Sling, Wicket, etc. These would all be left out of the door. Honestly, I don't like the idea of adding Jersey to an OSGi framework just for the sake of the Web Console. This does not sound right. > > 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. I understand and agree. But you said "*register* a JAX-RS bean". Where would that bean be registered ? > > 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, ...) Sure, I completely agree, that supporting other rendering technology (I, of course have a slight bias towards Apache Sling ;-) ) would be nice. But this should IMHO be possible without tying the Web Console to all these technologies. I opt for keeping the Web Console lightweight defining a simple API for extensions. To connect with other rendering technology, bridges could be defined. For example a Jersey bridge, which proxies JAX-RS beans into the Web Console registering proxy Servlets on behalf of the JAX-RS beans. Regards Felix > > 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 >>>>>> >
