Hi Marcin, Thanks for providing. I have taken a look and commented on your patch in the issue.
Ragards Felix Marcin Wilkos schrieb: > Hi, > I've just attached patch to https://issues.apache.org/jira/browse/FELIX-1015 > I hope it works like you wanted. Could you check it? > Greetings, > Marcin Wilkos > > 2009/6/10 Felix Meschberger <fmesc...@gmail.com> > >> Hi, >> >> Gert Vanthienen schrieb: >>> Felix, >>> >>> Like I said, I really do get your point about the dependencies. Not >>> sure I follow with the argument that it would lock the console into a >>> single presentation technology, because you can plugin different view >>> technologies into jersey and at this point in time, the only view >>> technology that's available for the web console plugins is using a >>> plain Servlet. >> Sure, but I my application does not care about Jersey, you are back to >> field one. >> >>> My suggestion would be to put the JAX-RS bean in the OSGi Service >>> Registry, just like we to with the Servlet right now. >> Ok, that would be good. Though.... >> >>> However, I do >>> like your suggestion for somehow building a bridge and hide the entire >>> view technology behind the Servlet (which is what almost all view >>> technologies eventually boil down to anyway). >> Great. So lets stay on the Servlet track for now ;-) >> >>> This would require us >>> to get the brandability issue solved, so we no longer need to work >>> with the AbstractConsolePlugin to draw the headers. So I guess it >>> would make sense to make that the next task item on Marcin's list. >> Absolutely ! >> >> I see a two-step approach here: >> >> (1) We keep the AbstractConsolePlugin but add support for branding to >> it. This helps all existing AbstractConsolePlugin extensions since they >> don't have to be modified. This is part of FELIX-1015 [1] for which >> Thomas Diesler already proposed a solution. >> >> (2) Add support for plain servlets. When the console encounters a >> Servlet not extending the AbstractWebConsolePlugin, it would create a >> proxy internally, which extends the AbstractWebConsolePlugin and >> forwards to the registered servlet. This would be part of FELIX-1043 >> [2]. I have attached a patch implementing this proposal. >> >> Regards >> Felix >> >> >> [1] https://issues.apache.org/jira/browse/FELIX-1015 >> [2] https://issues.apache.org/jira/browse/FELIX-1043 >> >>> Regards, >>> >>> Gert Vanthienen >>> ------------------------ >>> Open Source SOA: http://fusesource.com >>> Blog: http://gertvanthienen.blogspot.com/ >>> >>> >>> >>> 2009/6/10 Felix Meschberger <fmesc...@gmail.com>: >>>> 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 >>>>>>>>>> >
