portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <...@douma.nu>
Subject [Fwd: Wicket Portlet 2.0 support - status]
Date Mon, 19 Jan 2009 09:07:07 GMT

-------- Original Message --------
Subject: Wicket Portlet 2.0 support - status
Date: Mon, 19 Jan 2009 10:03:37 +0100
From: Ate Douma <ate@douma.nu>
Reply-To: dev@wicket.apache.org
To: Wicket Development <dev@wicket.apache.org>

Hi all,

Its been a long time before I had any time to work on the Wicket Portlet support but I'm (part
time) back in the game now.
Luckily Thijs Vonk and Antony Stubbs already have put a lot of effort into this too, especially
in getting Wicket running in a Portlet 2.0
container and provided several patches for doing so, see https://issues.apache.org/jira/browse/WICKET-1620

The current Wicket Portlet 1.0 support, leveraging some custom extensions provided by Portal
Bridges (ServletContextProvider and
PortletResourceURLFactory interfaces), while generic of nature and technically supportable
by any Portlet Container, have turned out to be
difficult to get supported or implemented by other portals except Jetspeed-2, especially the
PortletResourceURLFactory interface
(ServletContextProvider *is* supported by all/most Portlet containers nowadays).

Thijs Vonk and Antony Stubbs therefore have concentrated on replacing the usages of these
extensions (which from the beginning were
intentionally temporary anyway) by the now available Portlet 2.0 features (Thijs), as well
as adding support for new Portlet 2.0 features
(Events, Antony).

The chosen solution, as has been discussed on this list before, is to *replace* the current
Portlet 1.0 with Portlet 2.0 support *only*.
This means that, once this upgrade is done, Wicket will *not* work anymore on only Portlet
1.0 supporting portlet containers!
As I have expressed on this list before, I fully support that change, and as most portlet
containers nowadays do have Portlet 2.0 support
(Jetspeed-2 being an exception, but we're in the process of adding that very soon now), I
don't see that as a major issue anymore.

FYI: I've tested (part of) the patches from Thijs and Antony already and with reasonable success
although I did have to make some changes.
And (for now) I limited this to the existing Wicket Portlet support features. I did not yet
merge and test the Portlet Event features as
added by Antony as those really require core Wicket changes which I currently still consider
out of scope for Wicket 1.4 at least.
Furthermore, the Event handling changes need further discussion and technical changes which
I will come back on in another email sometime
later (for one, those changes currently always require a Portlet API to be available on the
classpath, even for plain web applications).

I've already got the (adapted) basic Portlet 2.0 patches more or less working on Pluto, Jetspeed-2
and SUN OpenPortal container (e.g. the
container that Liferay also uses). On JBoss and eXo these still do not work properly. Although
I haven't dived into why not (as I'm only a
Pluto and Jetspeed-2 committer, not knowledgeable on those other containers), I think I already
figured out some potential causes for this.

The handling of Portlet/Servlet request and response, especially with regard to Cookies, Header
parameters in general, content type and
buffering is not yet implemented correctly as required by the Portlet 2.0 specification (which
is *very* tricky in this regard).
Formally, none of the above (response) interactions concerning Cookies, Header parameters
and content type setting is supported from a
RequestDispatcher.include, but WicketPortlet currently (also with the patches) does *need*
to leverage an include call to be able to support
redirect handling from within Wicket itself.

As I'm currently working on the (proper) Portlet 2.0 API implementation in both Pluto and
Jetspeed-2, I'm quite on top of these spec
features and plan to (also) validate those against Wicket Portlet 2.0 support. And, for further
compliance and support validation, I'll keep
on testing Wicket against SUN OpenPortal container, JBoss Portal and eXo Portal too.

Once I get the *current* Wicket Portlet 1.0 support properly working again in these Portlet
2.0 containers (except for issues where they
themselves are not properly following the spec as I've already saw in some area's with SUN
Open Portal), I'd like to commit the upgrade to
Wicket Portlet 2.0 support against the Wicket trunk, e.g. targeting Wicket 1.4 release...

The changes I expect needed for this will *not* affect any core Wicket functionality, so far
all these changes will be contained within the
portlet specific classes and/or within code blocks executed within a portlet environment only.
And, the dependency on Portlet 1.0 API will need to be upgraded to the 2.0 API and the dependency
on the Portals Bridges Common jar will no
longer be needed.

New Portlet 2.0 features like the Event handling as provided by Antony will need further discussion
as I indicated above and for now I
expect those probably better wait until work on Wicket 1.5 starts.

Please stay tuned, I'll follow up on this as soon as possible.



To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org

View raw message