geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick McGuire <>
Subject Re: [DISCUSSION] What technology will the Geronimo 3.0 use for its web console?
Date Tue, 17 Nov 2009 10:35:47 GMT
Rex Wang wrote:
> 2009/11/17 Shawn Jiang < <>>
>     There were some voices on what technology the Geronimo 3.0 will
>     use for its web admin console. I list them here for discussion:
>     1, Change to Felix web console infrastructure.
>     Felix web console is based on http-service.  The developer need to
>     write servlet and register it as an OSGi service to contribute to
>     the web console.  Karaf is using felix console as its console. You
>     can see [1] for details on how to extend felix web console.   Is
>     writing servlet to replace current portlets in web console
>     acceptable ? 
> There is no need to use http services if a web container integrates to 
> osgi framework. IMO, writing servlets to replace currect portlets can 
> be seen as a sort of going backwards..
>     2, Keep to portlet, but upgrading pluto 1 to pluto 2.
>     Pluto 2 supports JSR 286 and is backwards-compatible to JSR 186. 
>     If we upgrade pluto to 2.0,  it seems we don't need to change much
>     existing geronimo web console code. Pluto 2 provide many new JSR
>     286 features[2] like publish/subscribe style asynchronous
>     communication between portlets, public render parameters, portlet
>     filter support,  Resource Serving support,....   
>     But IIUC, the major benifit to upgrate to pluto 2 is that we can
>     use Resource Serving to enable a native AJAX support in portlet. 
>     I'm not sure if other new features in pluto 2 can help with our
>     web console for now.
> IMO, this might be a better choice because of less time consuming, 
> lower risk..   I think we should spend more time on how to improve our 
> userbility, or find which part of our old codes has a bad code 
> logic/structure and need to improve. But not to try new frameworks and 
> re-writing.
I agree with your assessment here.  Taking a step backwards in how the 
console works really shouldn't be an option.  The plugability of the 
console really depends on having a portlet-based technology, so option 1 
isn't really an option.  Upgrading to pluto 2 could be a good step, but 
the focus really should be on how to improve the usability of the 
console and how to integrate the new management functions introduced by 
using OSGi into the console infrastructure.  If upgrading to pluto 2 
makes this easier and can save time, this would be good.  On the other 
hand, we need to be careful to not make the pluto upgrade the main focus 
of the effort and lose sight of the original objective.


>     3,     To start the web console over with JSF, wicket[3], or any
>     other framework.
>     A powerful framework can reduce the  programing/debug complexity
>     that exists in current web console infrastructure.  But there are
>     risks to rewrite all the existing page/portlet.  We might want to
>     include one of them little by little by introducing JSF portlet
>     bridge[4], wicket portlet bridge, or other bridges.
> High risk, more time consuming.
> -Rex
>     Personally, I perfer to upgrade to pluto 2 firstly, then we can
>     see if we can leverage a framework to reduce the programing
>     complexity.  Any thoughts ?
>     [1]
>     [2]
>     [3]
>     [4]
>     -- 
>     Shawn

View raw message