MyFaces Tomahawk
  1. MyFaces Tomahawk
  2. TOMAHAWK-1402

PortletExternalContextWrapper does not implement getRequestCharacterEncoding for wrapped ExternalContext.

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.1.8
    • Fix Version/s: 1.1.9
    • Component/s: Portlet_Support
    • Labels:
      None
    • Environment:
      Tomahawk on JSF RI within the JBOSS Portlet Bridge, the portlet bridge fails to resolve the Encoding and throws an UnsupportedOperationException. Resolving fails in the PortletExternalContextWrapper, which lacks a getRequestCharacterEncoding.

      Description

      PortletExternalContextWrapper implements
      setResponseCharacterEncoding
      getResponseCharacterEncoding,
      setRequestCharacterEncoding,
      but not a getRequestCharacterEncoding.
      When the wrapper is used as the external faces context in a portlet bridge (e.g. JBOSS portlet bridge), the resolving of the RequestCharacterEncoding defaults to the inherited method from ExternalContext (which returns an invalid encoding).

      Implementing getRequestCharacterEncoding analogue to getResponseCharacterEncoding resolved the issue for me, the PortletExternalContextWrapper now works in a portlet environment.

      The Bug prevents usage of Tomahawk within the JBOSS portlet bridge.

        Activity

        FR Weichand created issue -
        FR Weichand made changes -
        Field Original Value New Value
        Description PortletExternalContextWrapper implements
        setResponseCharacterEncoding
        getResponseCharacterEncoding,
        setRequestCharacterEncoding,
        but not a getRequestCharacterEncoding.
        When the wrapper is used as the external faces context in a portlet bridge (e.g. JBOSS portlet bridge), the resolving of the RequestCharacterEncoding defaults to the inherited method from ExternalContext (which returns an invalid encoding).

        Implementing getRequestCharacterEncoding analogue to getResponseCharacterEncoding resolved the issue for me, the PortletExternalContextWrapper now works in a portlet environment.
        PortletExternalContextWrapper implements
        setResponseCharacterEncoding
        getResponseCharacterEncoding,
        setRequestCharacterEncoding,
        but not a getRequestCharacterEncoding.
        When the wrapper is used as the external faces context in a portlet bridge (e.g. JBOSS portlet bridge), the resolving of the RequestCharacterEncoding defaults to the inherited method from ExternalContext (which returns an invalid encoding).

        Implementing getRequestCharacterEncoding analogue to getResponseCharacterEncoding resolved the issue for me, the PortletExternalContextWrapper now works in a portlet environment.

        The Bug prevents usage of Tomahawk within the JBOSS portlet bridge.
        FR Weichand made changes -
        Status Open [ 1 ] Patch Available [ 10002 ]
        Hide
        FR Weichand added a comment -

        Implemented getRequestCharacterEncoding() in the Wrapper, which simply hands over the method call to the _delegate.

        Show
        FR Weichand added a comment - Implemented getRequestCharacterEncoding() in the Wrapper, which simply hands over the method call to the _delegate.
        FR Weichand made changes -
        Attachment PortletExternalContextWrapper.java [ 12402120 ]
        Hide
        Leonardo Uribe added a comment -

        Thanks for provide this patch

        Show
        Leonardo Uribe added a comment - Thanks for provide this patch
        Leonardo Uribe made changes -
        Status Patch Available [ 10002 ] Resolved [ 5 ]
        Assignee Leonardo Uribe [ lu4242 ]
        Fix Version/s 1.1.9-SNAPSHOT [ 12313508 ]
        Resolution Fixed [ 1 ]
        Leonardo Uribe made changes -
        Component/s Portlet_Support [ 12310770 ]
        Leonardo Uribe made changes -
        Fix Version/s 1.1.9 [ 12314035 ]
        Fix Version/s 1.1.9-SNAPSHOT [ 12313508 ]
        Leonardo Uribe made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open Patch Available Patch Available
        10m 16s 1 FR Weichand 13/Mar/09 09:08
        Patch Available Patch Available Resolved Resolved
        74d 14h 9m 1 Leonardo Uribe 27/May/09 00:17
        Resolved Resolved Closed Closed
        20d 2h 18m 1 Leonardo Uribe 16/Jun/09 02:35

          People

          • Assignee:
            Leonardo Uribe
            Reporter:
            FR Weichand
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 0.5h
              0.5h
              Remaining:
              Remaining Estimate - 0.5h
              0.5h
              Logged:
              Time Spent - Not Specified
              Not Specified

                Development