Thanks for your ideas. I attached a new patch. What do you think about resource support for branding?
2009/6/16 Felix Meschberger <fmesc...@gmail.com> > 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 > >>>>>>>>>> > > >
