ICEfaces
  1. ICEfaces
  2. ICE-7791

Push application (Myfaces, WebSphere, Portal) throws IllegalStateException changing the characterEncoding

          Details

          • Type: Bug Bug
          • Status: Closed
          • Priority: Major Major
          • Resolution: Fixed
          • Affects Version/s: 3.0
          • Fix Version/s: EE-3.0.0.GA
          • Component/s: Framework
          • Labels:
            None
          • Environment:
            ICEFaces 3.0 + Myfaces 2.1.6 + WebSphere 7 + Portal 2

            Description

            During processing of a push request, the ICEfaces CharacterEncodingHandler class tries to change the characterEncoding. In a WebSphere environment, this call throws an IllegalStateException

            Caused by: java.lang.IllegalStateException: This method must not be called after the HTTP-Body was accessed !
                    at com.ibm.ws.portletcontainer.core.impl.PortletRequestImpl.setCharacterEncoding(PortletRequestImpl.java:1103)
                    at org.portletfaces.bridge.context.ExternalContextImpl.setRequestCharacterEncoding(ExternalContextImpl.java:791)
                    at org.icefaces.impl.util.CharacterEncodingHandler.setCharacterEncoding(CharacterEncodingHandler.java:76)
                    at org.icefaces.impl.util.CharacterEncodingHandler.isResourceRequest(CharacterEncodingHandler.java:65)
                    at javax.faces.application.ResourceHandlerWrapper.isResourceRequest(ResourceHandlerWrapper.java:68)
                    at javax.faces.application.ResourceHandlerWrapper.isResourceRequest(ResourceHandlerWrapper.java:68)
                    at javax.faces.application.ResourceHandlerWrapper.isResourceRequest(ResourceHandlerWrapper.java:68)
                    at org.portletfaces.bridge.BridgeImpl.doFacesRequest(BridgeImpl.java:506)

            There are some additional comments here:
            https://issues.apache.org/jira/browse/PORTLETBRIDGE-48

              Issue Links

              blocks

              New Feature - A new feature of the product, which has yet to be developed. IPCK-259 Add ICEfaces EE Support for WebSphere Portal 7

              • Major - Major loss of function.
              • Closed

                Activity

                Ascending order - Click to sort in descending order
                Hide
                Permalink
                Greg Dick added a comment -

                A workaround in the code exists by quietly catching the IllegalStateException in our class and carrying on. The code, for the purposes of testing in WebSphere can ignore this attempt. Deryk thought this behaviour should be farmed out to a WebSphere specific class in the EE delivery. How that might be and how it would be loaded first in the resourceHandler chain was open to debate.

                Show
                Greg Dick added a comment - A workaround in the code exists by quietly catching the IllegalStateException in our class and carrying on. The code, for the purposes of testing in WebSphere can ignore this attempt. Deryk thought this behaviour should be farmed out to a WebSphere specific class in the EE delivery. How that might be and how it would be loaded first in the resourceHandler chain was open to debate.
                Hide
                Permalink
                Deryk Sinotte added a comment -

                As part of:

                http://jira.icefaces.org/browse/ICE-5977

                and its related Mojarra issue:

                http://java.net/jira/browse/JAVASERVERFACES-1767

                we added a call to calculate and set the conent encoding in a ResourceHandler that runs before other resource handlers so that Glassfish wouldn't complain that the content encoding wasn't being set too late. Unfortunately, this little workaround for Glassfish causes WebSphere Portal to complain via the server log as noted in the original description.

                I've added some logic to detect whether we are running in WebSphere Portal and, if so, not to call the setContentEncoding in our custom handler as it was only designed to help Glassfish.

                Show
                Deryk Sinotte added a comment - As part of: http://jira.icefaces.org/browse/ICE-5977 and its related Mojarra issue: http://java.net/jira/browse/JAVASERVERFACES-1767 we added a call to calculate and set the conent encoding in a ResourceHandler that runs before other resource handlers so that Glassfish wouldn't complain that the content encoding wasn't being set too late. Unfortunately, this little workaround for Glassfish causes WebSphere Portal to complain via the server log as noted in the original description. I've added some logic to detect whether we are running in WebSphere Portal and, if so, not to call the setContentEncoding in our custom handler as it was only designed to help Glassfish.

                  People

                  • Assignee:
                    Greg Dick
                    Reporter:
                    Greg Dick
                  • Votes:
                    0 Vote for this issue
                    Watchers:
                    0 Start watching this issue

                    Dates

                    • Created:
                      Updated:
                      Resolved: