Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Received-SPF: pass (athena.apache.org: domain of marcin.wilkos@gmail.com
 designates 209.85.219.208 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=GEERxUYUApXawS8kebE9Xp+NOuSsk6RCXut6VFzx24Z3jSnJ1mcjCz4aIilT81ziQW
         o0iY6St9q3GPLzZ0ywflWKpoibw1k153clx0QdjCvLajg1QZ52tmbyeRabl58n0me2oy
         avaSALg4PBM02O7VoAX+0Gj/O0QZKHDHPD4xg=
MIME-Version: 1.0
In-Reply-To: <4A2F7C80.2010203@gmail.com>
References: <E8ECEFCFBCC81F4EB23B896D7C06A6EDFB5AAF@CHNMICMB02.ManTech.com>
	 <4A2E0F21.2080209@gmail.com>
	 <67a6ab030906090718ya6be0f4jba0850611a924839@mail.gmail.com>
	 <4A2EA0C8.50501@gmail.com>
	 <67a6ab030906100012g54d59b85tc9fcf0b3a8f625e@mail.gmail.com>
	 <4A2F61C7.6060601@gmail.com>
	 <67a6ab030906100056n510e550g726d5d329d5edf0b@mail.gmail.com>
	 <4A2F7C80.2010203@gmail.com>
Date: Tue, 16 Jun 2009 02:16:13 +0200
Message-ID: <b1af83ea0906151716q10454accx2cf7687ebb73c619@mail.gmail.com>
Subject: Re: Google Summer of Code
From: Marcin Wilkos <marcin.wilkos@gmail.com>
To: dev@felix.apache.org
Content-Type: multipart/alternative; boundary=00163646b9921d8ad7046c6c150f

--00163646b9921d8ad7046c6c150f
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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

--00163646b9921d8ad7046c6c150f--