Thijs wrote:
Hi Ate,
Your email sounds very promising. I'm very happy that Portlet2 is going
into Wicket.
In your email you mentioned Liferay using Sun's portlet-container.
Liferay doesn't by default use the Sun portlet container implementation,
but it's own. We spoke to Brian Chan (Liferay's CEO) about this. They
are probably not going to put the SUN implementation as their current
default because of performance issues with that implementation. This is
of interest for Wicket working in Liferay.
OK, I wasn't aware of that.
I'll need to add Liferay too then to the list of portals to validate against
(or maybe you can do that?).
I have some updates on the portlet 2 patch based on some experience I
have with Liferay over the last few months of trying to get everything
to work. (I've also tested this with pluto trunk)
I haven't posted any updated to WICKET-1620 as I wasn't really
successful. But I had some luck last week and was planning on uploading
a new version of Antony's patch with some updated things.
These include.
* use of RequestDispatcher.forward when using serveResource instead
of RequestDispatcher.include. (this fixes resourceServing in Liferay's
portlet-container implementation)
Check, same thing required for Pluto (not for Jetspeed or SUN OpenPortal though which both plug in a custom BufferedResponseWrapper to
handle this)
In my local changes I already did the same.
Not 100% sure yet though if using a forward the right way to solve this: when using a forward there is no way of further handling the
response after that... And, from within Wicket there might be cases when a redirect could be issued. Currently, this is handled within the
WicketPortlet by simply reinvoking Wicket during the same request (and ignoring any response output so far). When using a forward though
this won't be possible anymore. Its not clear yet to me how important that use-case might be (for serverResource requests), but its
something to keep in mind. It might be necessary to use the same solution as applied by Jetspeed and OpenPortal to deal with this *within*
Wicket to keep it independent from portlet container implementations.
Note: for Action and Render requests this will be required anyway and I'm
already working on that.
* use of the get/setResourceId for resource-requests instead of the
render-parameters.
Cool, I haven't come to that part of the spec. If you have supportive code for
Wicket on that, please share :)
* displaying errorpages correctly in portlet mode.
Cool again, looking forward to it :)
But I understand from your email that you are not going to commit
Antony's patch, just an evolved version of mine (without the event stuff)?!
So I was wondering if you would you still like to see my modifications?
Yes on both accounts. The patches from Antony concerning Event handling definitely will become important for Wicket 1.5, but they are too
invasive in the Wicket core functionality (in their current form that is) to target Wicket 1.4
And if yes, shall I upload them in an updated version of Antony's patch
or do you have a patch that does not contain all the event stuff?
If possible I'd prefer a slim patch without the Event handling. I'll create a patch of my local changes shortly as a separate patch file to
WICKET-1620 which you than can to merge your changes with.
Regards,
Ate
best regards
Thijs
ps. on of the things I noticed is that pluto isn't setting
(resource)response headers correctly, as they are not (always)returned
to the client. I haven't looked at this closely enough to know if this
is a known issue or not. I'm happy to provide details at your request.
On 19-1-2009 10:03, Ate Douma wrote:
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
