[
https://issues.apache.org/jira/browse/WICKET-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12668174#action_12668174
]
Ate Douma commented on WICKET-2058:
-----------------------------------
Thijs pinged me offline about an problem with the new patch on Liferay
concerning the WicketPortlet always using requestDispatcher.include for
invoking Wicket, and not .forward during a serveResource.
I'll try to explain here as it is important information for anyone trying to
understand how Portlet dispatching to Servlets works and why a rd.include is
needed for a Portlet "bridge" like WicketPortlet.
Once this patch is committed, I'll move this technical explanation to the wiki.
A Portlet.serveResource request is intended to be used when full control is
needed on the response of the Portlet, like being able to set the contentType,
characterEncoding, contentLength, etc.
Especially for Wicket Ajax support or serving dynamically generated resources
like images/captcha etc. the full control over the response output is needed.
As Wicket itself is invoked by WicketPortlet through the
PortletRequestDispatcher, the portlet can either use .forward or .include for
this.
Per the spec. only when using a .forward this full control is available to the
invoked servlet, when using .include this is not the case (equal to and same
restrictions apply as when using a Servlet RequestDispatcher).
So, the logical choice would *seem* to be using .forward for (at least) the
serverResource request.
But (as one may already have expected), this turns out to be not such a good
idea after all...
The problem with using RequestDispatcher.forward is that *before* it returns to
the caller (e.g. WicketPortlet) the container (servlet or portlet) is required
to flush, commit and close the response!
That means, that the output produced by Wicket already will have to be send out
to the Portlet container/Portal before WicketPortlet has a chance to inspect
and evaluate the outcome.
For proper management and control of Wicket from WicketPortlet that is bad
news, as Wicket itself has no real knowledge its being run within a Portlet and
so proper handling of specific state or direction cannot be done appropriate
for the Portlet environment.
Specific conditions which need *post-processing* by WicketPortlet *before* the
response is flushed and send out to the Portal, include error status/message
handling and possible (resource) response redirecting.
While those conditions are not common use-cases, not being able to handle them
appropriately *when* they occur really can kill off Wicket for serious
production quality usages in a Portlet environment.
I solved this problem (requiring full control over the response while needing
to use requestDispatcher.include to invoke Wicket) by wrapping the
HttpServletResponse within WicketFilter right away and temporarily caching all
output written to the response (cookies, headers, contentType and buffer
related settings, error status/message, redirectLocation, as well as the
content itself) in a WicketResponseState object.
Wicket itself therefore simply can write out to the response as it thinks is
needed, but nothing gets written to the real (Portlet) response until *after*
the requestDispatcher.include returns to WicketPortlet.
After the .include, WicketPortlet can provide its own evaluation of the
response outcome and when needed decide to "override" or provide specific
handling like in the case of an error status set or when a redirect was issued
by Wicket.
AFAICS, using requestDispatcher.forward for invoking Wicket simply is no option
here.
While standard use- and test-cases will work just fine using .forward (and it
does: I did test that myself too against Pluto, Jetspeed-2 and OpenPortal), if
we also want to be able to properly handle the not so common,
but (because of that) really critical use-cases too, using
requestDispatcher.include with temporarily reponse buffering is the only
solution.
Now, Thijs told me offline Liferay Portal somehow isn't capable of handling a
PortletRequestDispatcher.include call from within a Portlet.serverResource
request.
That of course is a major problem, but in my view (and please bear with me: I
don't have the exact details yet for this) it is most likely Liferay itself at
the cause of this.
Being able to use PortletRequestDispatcher.include from within
Portlet.serveResource request (or any Portlet request for that matter) is an
explicit requirement of the Portlet 2.0 specification.
And Apache Pluto and Jetspeed-2 as well as SUN OpenPortal have no problem at
all handling this.
So, while the exact reason of the problem on Liferay Portal still needs to be
determined, using RequestDispatcher.include cannot and shouldn't be the cause
of it.
Anway, lets wait and see if Thijs can determine the exact cause and then we'll
evaluate if an adjustment for the WicketPortlet patch should or shouldn't be
required.
> Upgrade Wicket Portlet Support to only use native Portlet API 2.0
> ------------------------------------------------------------------
>
> Key: WICKET-2058
> URL: https://issues.apache.org/jira/browse/WICKET-2058
> Project: Wicket
> Issue Type: Sub-task
> Components: wicket-portlet
> Affects Versions: 1.4-RC1
> Reporter: Ate Douma
> Assignee: Ate Douma
> Fix For: 1.4-RC2
>
> Attachments: wicket-2058-patch.txt
>
>
> WICKET-1620 is an overall issue for provide full blown Portlet API 2.0
> support to Wicket, including *new* features like Portlet Eventing.
> As those new features still will require further discussion *and* require
> some critical changes to the core Wicket API, the target for WICKET-1620 is
> currently set for version 1.5
> However, as the current Portlet 1.0 support in Wicket turned out not very
> well supported by other Portals than Apache Jetspeed-2.
> For Portlet 1.0 containers, a few custom, Portal SPI interface based
> enhancements, as defined by the Apache Portals Bridges project, need to be
> provided by a portal (container) to enable Wicket in a Portlet environment.
> This turned out to be more difficult then expected.
> But as Portlet API 2.0 now is generally available for all/most portlet
> containers, those custom enhancements are no longer needed!
> The goal has been from the outset to replace these custom interfaces with
> native Portlet API 2.0 features as soon as it would be generally available.
> As the latter is now the case, I created this separate subtask of WICKET-1620
> to *only* upgrade the current Wicket Portlet features to Portlet API 2.0
> So, no new features, nor any real changes needed to the Wicket core.
> This way, the impact of this upgrade can be done more or less "painless" and
> without any side-effect to Wicket core itself, but then make it much easier
> to enable Wicket generically in a Portlet (2.0) environment.
> I've taken the initial patches provided by Thijs Vonk, added some general
> improvements from the extensive patches from Antony Stubbs (but not all, and
> none of the "new" features) as starting point.
> After adding several further enhancements and fixes and even a few
> workarounds for incomplete/incorrect Portlet API 2.0 implementations of some
> containers (e.g. OpenPortal, JBoss Portal), I've now finally a new patch
> available with which Wicket Portlet works great on the following Portlet API
> 2.0 containers: Apache Pluto 2.0 (trunk development), Apache Jetspeed-2 2.2
> (trunk development), Sun OpenPortal Container 2.01_01
> I've also tested against Exo Portal (exo-pc-2.0.5-tomcat) and JBoss Portal
> 2.7.
> Exo Portal Container 2.0.5 however turned out to not work well, it looks like
> some serious Portlet API 2.0 requirements are not working yet
> JBoss Portal 2.7 already was much better, plain Wicket features seems all to
> work fine, but Ajax support still doesn't work.
> I put a few temporary "workarounds" for JBoss Portal quirks (strange windowId
> format containing embedded '/' characters, and some
> UnSupportedOperationExceptions thrown on Spec required API methods!).
> And for Sun OpenPortal I also needed to put in a temporary workaround, but
> those are rather minor issue which (AFAIK) don't really limit the usage of
> Wicket.
> As I understood from Thijs Vonk he's primarily working with Liferay Portal
> which I haven't had time yet to test against myself. I hope and expect Thijs
> will look into that.
> I'll attach my new patch to this issue shortly. Please all review and test.
> As building a Wicket 1.4-RC2 release is scheduled (anew) for this weekend,
> I'd like to get some confirmation from especially Thijs if/how this patch
> works out on Liferay.
> If nothing turns out to be seriously broken, I plan to commit this to wicket
> trunk *before* 1.4-RC2 is created so that everyone interested in
> WicketPortlet will have a good new baseline for further improvements and
> testing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
