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 >>>>>>>> >
