Rex Wang wrote:
2009/11/17 Shawn Jiang <[email protected] <mailto:[email protected]>>
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.
Rick
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
