geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rex Wang <>
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 <>

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


> 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