felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcin Wilkos <marcin.wil...@gmail.com>
Subject Re: Google Summer of Code
Date Tue, 16 Jun 2009 00:16:13 GMT
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 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
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.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
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
> >>>>>>>>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message