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.
Regards,
Ate
