[
https://issues.apache.org/jira/browse/WICKET-4019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13140316#comment-13140316
]
Peter Pastrnak edited comment on WICKET-4019 at 10/31/11 5:02 PM:
------------------------------------------------------------------
Finally I've realized, why the whole response has to be cached (as it was in
wicket portlet 1.4). WicketPortlet uses dispatcher.include to 'forward' the
request to the WicketFilter and as the servlet specification does not allow
setting headers (e.g. contentType) inside an include, the response has to be
cached and flushed just after the include ends. It is currently not possible to
use the dispatcher.forward instead of the include, as after the forward would
be the response closed and it would not be possible to do another forward
(after wicket redirect). We could try to find some workaround, but it is easier
to implement a file system cache for this, so I've reverted the flushing
mechanism and implemented a simple file system cache that uses
File.createTempFile (might be changed in the future) as soon as the response
reaches a limit (currently set to 64kB).
was (Author: pasto):
Finally I've realized, why the whole response has to be cached (as it was
in wicket portlet 1.4). WicketPortlet uses dispatcher.include to 'forward' the
request to the WicketFilter and as the servlet specification does not allow
setting headers (e.g. contentType), the response has to be cached and flushed
just after the include ends. It is currently not possible to use the
dispatcher.forward instead of the include, as after the forward would be the
response closed and it would not be possible to do another forward (after
wicket redirect). We could try to find some workaround, but it is easier to
implement a file system cache for this, so I've reverted the flushing mechanism
and implemented a simple file system cache that uses File.createTempFile (might
be changed in the future) as soon as the response reaches a limit (currently
set to 64kB).
> Portlet Support 1.5
> -------------------
>
> Key: WICKET-4019
> URL: https://issues.apache.org/jira/browse/WICKET-4019
> Project: Wicket
> Issue Type: New Feature
> Components: wicket
> Affects Versions: 1.5-RC7
> Reporter: Peter Pastrnak
> Attachments: PortletServletRequestWrapper.java, ResponseState.java,
> Wicket - Portlet.htm, wicket-portlet-1.5.0.zip, wicket-portlet-1.5.1.1.zip,
> wicket-portlet-1.5.1.2.zip, wicket-portlet-1.5.1.3.zip,
> wicket-portlet-1.5.1.4.zip, wicket-portlet-1.5.1.5.zip,
> wicket-portlet-1.5.1.zip, wicket-portlet-1.5.RC7.zip, with bind(this).jpg,
> without bind(this).jpg
>
>
> Url returned by the RequestMapper does not seem to be properly rendered, as
> it does not encode question mark character in the Url parameter value (I
> haven't checked the w3c spec, but at least Liferay Portal seems to require it
> to be encoded)
> The reason is this definition in the UrlEncoder:
> case QUERY :
> // to allow direct passing of URL in query
> dontNeedEncoding.set('/');
> // to allow direct passing of URL in query
> dontNeedEncoding.set('?');
> Currently URL "http://host/file?param=a?b"; would be encoded as
> "http://host/file?param=a?b";, instead of "http://host/file?param=a%3Fb";
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
