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
                Greg Dick created issue -
                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.
                Ken Fyten made changes -
                Field Original Value New Value
                Salesforce Case []
                Fix Version/s EE-3.0.0.GA [ 10262 ]
                Assignee Priority P2
                Affects Version/s 3.0 [ 10241 ]
                Assignee Greg Dick [ greg.dick ]
                Ken Fyten made changes -
                Salesforce Case []
                Component/s Framework [ 10013 ]
                Ken Fyten made changes -
                Link This issue blocks IPCK-259 [ IPCK-259 ]
                Repository Revision Date User Message
                ICEsoft Public SVN Repository #28173 Mon Mar 05 16:37:23 MST 2012 deryk.sinotte ICE-7791: reflection based code to avoid unnecessary logging from WebSphere when we try to set the encoding (adjusted message to reflect proper JIRA)
                Files Changed
                Commit graph MODIFY /icefaces3/trunk/icefaces/core/src/main/java/org/icefaces/impl/util/CharacterEncodingHandler.java
                Commit graph MODIFY /icefaces3/trunk/icefaces/core/src/main/java/org/icefaces/util/EnvUtils.java
                Repository Revision Date User Message
                ICEsoft Public SVN Repository #28174 Mon Mar 05 16:46:06 MST 2012 deryk.sinotte ICE-7791: reflection based code to avoid unnecessary logging from WebSphere when we try to set the encoding
                Files Changed
                Commit graph MODIFY /icefaces3/branches/icefaces-3.0.x-maintenance/icefaces/core/src/main/java/org/icefaces/impl/util/CharacterEncodingHandler.java
                Commit graph MODIFY /icefaces3/branches/icefaces-3.0.x-maintenance/icefaces/core/src/main/java/org/icefaces/util/EnvUtils.java
                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.
                Deryk Sinotte made changes -
                Status Open [ 1 ] Resolved [ 5 ]
                Resolution Fixed [ 1 ]
                Ken Fyten made changes -
                Status Resolved [ 5 ] Closed [ 6 ]
                Assignee Priority P2

                  People

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

                    Dates

                    • Created:
                      Updated:
                      Resolved: