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 <[email protected]>: >> 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:[email protected]] >>>> Sent: Monday, June 08, 2009 17:32 >>>> To: [email protected] >>>> 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 >>>> >
