[
https://issues.apache.org/jira/browse/WICKET-2387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12770966#action_12770966
]
Eric Gulatee commented on WICKET-2387:
--------------------------------------
Response from IBM below.
Basically, the response is:
"Working as intended in WPS 6.1, They intend to implement new 2 phase rendering
at some point in the future".
This limits use of Wicket & WPS 6.1
Any comments or suggestions of a workaround? (I realize this isn't a Wicket
issue, however from my standpoint a wicket workaround would be greatly welcome)
----------------------------------------
his lies in the nature of the render phase of a portal. Since portlets
only render parts of a page they cannot modify the headers of the HTTP
request.
The servlet spec says this to the isCommited method:
"Returns a boolean indicating if the response has been committed. A
committed response has already had its status code and headers
written."
Due to the fact the portlets are written as parts of the page they
cannot change the headers in the render phase and so isCommited() will
never return true in render phase (all doXXX methods).
This changed when we look at resource serving. In a resource response
the Portlet is allowed to change the headers. So isCommitted will
return true here as long no data was written to the output
writer/stream.
In one of the next versions, Portal will support a 2-phase rendering
approach where users can also set headers in render phase as described
in chapter "PLT.11.1.4.3 The Render Part Request Attribute for Setting
Headers in the Render Phase" of the portlet
spec.
=============================================================
As L3 has mentioned the current behavior is working as designed. However there
are plans to add a two phase rendering approach in a future release, however L3
has not provided any specific information about which release will contain this
feature.
> Failure using a Redirect strategy in a Websphere Portal 6.1 Portlet due to
> response already committed
> -----------------------------------------------------------------------------------------------------
>
> Key: WICKET-2387
> URL: https://issues.apache.org/jira/browse/WICKET-2387
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.4-RC7
> Environment: IBM Java 1.5, WebSphere 6.1
> Reporter: Eric Gulatee
> Assignee: Ate Douma
>
> When the following Authorization Stategy is set for in a WPS 6.1 Portlet
> getSecuritySettings().setAuthorizationStrategy(new IAuthorizationStrategy() {
> public boolean isInstantiationAuthorized(Class componentClass) {
> if
> (AuthenticatedWebPage.class.isAssignableFrom(componentClass)) {
> if (((SignInSession) Session.get()).isSignedIn()) {
> return true;
> }
> throw new
> RestartResponseAtInterceptPageException(SignInPage.class);
> }
> return true;
>
> }
> public boolean isActionAuthorized(Component component, Action
> action) {
> return true;
> }
> });
> We get the following stacktrace
> aused by: java.lang.IllegalStateException: clearBuffer(): illegal
> state--> stream is committed
> at
> com.ibm.wsspi.webcontainer.util.BufferedServletOutputStream.clearBuffer(
> BufferedServletOutputStream.java:497)
> at
> com.ibm.ws.webcontainer.srt.SRTServletResponse.reset(SRTServletResponse.
> java:880)
> at
> javax.servlet.ServletResponseWrapper.reset(ServletResponseWrapper.java:
> 228)
> at
> javax.servlet.ServletResponseWrapper.reset(ServletResponseWrapper.java:
> 228)
> at
> javax.servlet.ServletResponseWrapper.reset(ServletResponseWrapper.java:
> 228)
> at
> javax.servlet.ServletResponseWrapper.reset(ServletResponseWrapper.java:
> 228)
> at
> com.ibm.ws.portletcontainer.core.impl.PortletResponseImpl.reset(PortletR
> esponseImpl.java:355)
> at
> org.apache.wicket.protocol.http.portlet.OSCWicketPortlet.processMimeResp
> onseRequest(OSCWicketPortlet.java:138)
> at
> org.apache.wicket.protocol.http.portlet.OSCWicketPortlet.processRequest(
> OSCWicketPortlet.java:80)
> at
> org.apache.wicket.protocol.http.portlet.WicketPortlet.doView(WicketPortl
> et.java:469)
> at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:328)
> Which IBM has determined the cause to being:
> The cause is a PortletResponse#reset() call after the response has been
> commited. A response is for example committed after the headers were
> written to the client.
> I am guessing that wicket is outputting something and then deciding to do a
> redirect thus causing the failure? IS this something on the Wicket or
> WAS/WPS 6.1 side?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
