[ 
https://issues.apache.org/jira/browse/WICKET-2387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12773222#action_12773222
 ] 

Eric Gulatee commented on WICKET-2387:
--------------------------------------

By removing request.getAttributes() & setAttributes and using the constant 
instead as well as only doing a reponse.reset() ONLY if the response was not 
committed, I was able to get this working.  [Albeit I have no clue of the 
implications]

This Portlet 2.0 support seems to be dependant on something that a PortalServer 
may not implement for security reasons.  
I understand may only be affecting WebSphere Portal at the moment, but unclear 
to me if this Wicket Portlet Impl is dependant on something that may not be 
mandatory to be implemented.  

I am going to link this back to the more geneirc Portlet 2.0 support.  Seeing 
as I'm not sure this is only a Websphere Portal issue.  (It may be)

> 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.3
>         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.

Reply via email to