felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@gmail.com>
Subject Re: Google Summer of Code
Date Wed, 10 Jun 2009 09:27:28 GMT

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.


[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 <fmeschbe@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 <fmeschbe@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 <fmeschbe@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
>>>>>>> appears to be loaded via Spring.  Loading plugins this way doesn't
>>>>>>> AbstractWebConsolePlugin as it is "advertised" and many things
>>>>>>> don't work (activate() and deactivate() are never called,
>>>>>>> getBundleContext() returns null, etc).  It looks like a lot of
>>>>>>> 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
>>>>>> 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
>>>>>> interface javax.servlet.Servlet. For the web console to pick up this
>>>>>> Servlet service as service property named "felix.webconsole.label"
>>>>>> be set to a single, non-empty string providing the URL path segment
>>>>>> 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
>>>>>> to add to or replace the standard GET method handling.
>>>>>> Plugin Initialization: You have to initialize the plugin yourself
>>>>>> calling the activate(BundleContext) method before registering the
>>>>>> as a service. At the end you should call the deactivate() method
>>>>>> 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
>>>>>> I am going to update the web console documentation page [1] with
>>>>>> more information here ....
>>>>>>> Perhaps I missed the proper way to initialize a webconsole plugin
>>>>>>> get at the utility methods.  If not, I would suggest refactoring
>>>>>>> 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
>>>>>>> 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 
>>>>>>> (941) 377-6775 x208     unreasonable man.    George Bernard Shaw
>>>>>>>> -----Original Message-----
>>>>>>>> From: Marcin Wilkos [mailto:marcin.wilkos@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
>>>>>>>> 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
>>>>>>>> patch. Gert
>>>>>>>> checked it and uploaded to svn.
>>>>>>>> Regards,
>>>>>>>> Marcin Wilkos

View raw message