geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rex Wang <rwo...@gmail.com>
Subject Re: [DISCUSSION] What technology will the Geronimo 3.0 use for its web console?
Date Tue, 17 Nov 2009 09:17:19 GMT
2009/11/17 Shawn Jiang <genspring@gmail.com>

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


> 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]
> http://felix.apache.org/site/extending-the-apache-felix-web-console.html
> [2]
> http://www.ibm.com/developerworks/websphere/library/techarticles/0803_hepper/0803_hepper.html
> [3] http://wicket.apache.org/
> [4] http://myfaces.apache.org/portlet-bridge/index.html
>
>
> --
> Shawn
>

Mime
View raw message