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 Tue, 16 Jun 2009 07:09:38 GMT
Hi Marcin,

Thanks for providing. I have taken a look and commented on your patch in
the issue.


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 <fmeschbe@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 <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
>> to
>>>>>>> render the 'main' contents of the web console plugin page, but
>> 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
>>>>>>> for the extension bundle while making it easier to implement
>>>>>>> uris/actions without having to override the doGet/doPost methods
>>>>>>> allow us to use some other template engine/language (JSP, Lift,
>>>>>>> in the extension bundle without the need for the felix web console
>>>>>>> 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
>>>>>>> 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.
>> didn't
>>>>>>>>> investigate how the core plugins are loaded but the features
>>>>>>>>> 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
>> 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,
>> 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
>> 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
>> 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
>> 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
>> works
>>>>>>>> great once you get around the corners). For instance it creates
>>>>>>>> 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
>> points.
>>>>>>>> I am going to update the web console documentation page [1]
>> some
>>>>>>>> more information here ....
>>>>>>>>> Perhaps I missed the proper way to initialize a webconsole
>> and
>>>>>>>>> get at the utility methods.  If not, I would suggest
>> 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
>>>>>>>>> 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
>>>>>>>>>> -----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 be
>>>>>>>>>> sending weekly
>>>>>>>>>> reports to this list.
>>>>>>>>>> In last week I focused on first extension for felix
>>>>>>>>>> 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

View raw message