[ http://issues.apache.org/jira/browse/BEEHIVE-1029?page=all ]

Carlin Rogers updated BEEHIVE-1029:
-----------------------------------

    Attachment: j1029-repro.zip

Attaching a zip file containing a simple page flow with a popup to repro and 
test this issue.

Please note that this test is dependent on the servlet container. Servlet
containers have different ways to be configured to specify
the character encoding used to decode the URI bytes, after %xx
decoding the URL. Here are the instructions to set up either Tomcat
or WebLogic...

Also, in the Servlet spec there is a difference between what happens in a GET 
and a POST.
- With GET the URLs encode non-ASCII characters in UTF-8. 
- For POST, the header should have a content-type field that specifies the 
actual character encoding of the body.

To configure Tomcat 5.0.x for this test you need to follow these two steps.
1) Add URIEncoding="UTF-8" to the appropriate connector in the server.xml
file. This will work for GET only on Tomcat. Edit $CATALINA_HOME/conf/server.xml
and add the attribute URIEncoding="UTF-8" to  the
<Connector port="8080"... />. For example,

  <Connector port="8080"
             maxThreads="150"
             minSpareThreads="25"
             maxSpareThreads="75"
             enableLookups="false"
             redirectPort="8443"
             acceptCount="100"
             debug="0"
             connectionTimeout="20000"
             disableUploadTimeout="true"
             URIEncoding="UTF-8" />

2) To set the encoding correctly for POST requests with multibyte data
in the form, you can create a servlet filter that sets the encoding
to UTF-8 on the incoming request. There are lots of examples of this
type of configuration on the web. The src subdirectory of this example
contains a Servlet filter that can be used. If the incoming request
is a POST method and request.getCharacterEncoding() is null, then
it will call request.setCharacterEncoding("UTF-8");

To use this, you will need to add something like this to your
WEB-INF/web.xml

   <filter>
       <filter-name>TestFilter</filter-name>
       <filter-class>TestFilter</filter-class>
   </filter>

   <filter-mapping>
       <filter-name>TestFilter</filter-name>
       <url-pattern>/*</url-pattern>
       <dispatcher>FORWARD</dispatcher>
       <dispatcher>REQUEST</dispatcher>
       <dispatcher>INCLUDE</dispatcher>
   </filter-mapping>

For WebLogic 9.x, just add this to your WEB-INF/weblogic.xml

    <jsp-descriptor>
      <encoding>UTF-8</encoding>
    </jsp-descriptor>

    <charset-params>
      <input-charset>
        <resource-path>/*</resource-path>
        <java-charset-name>UTF-8</java-charset-name>
      </input-charset>
    </charset-params>


> Multibyte characters not supported correctly with the retrievePopupOutput for 
> NetUI tag.
> ----------------------------------------------------------------------------------------
>
>          Key: BEEHIVE-1029
>          URL: http://issues.apache.org/jira/browse/BEEHIVE-1029
>      Project: Beehive
>         Type: Bug
>   Components: NetUI
>     Versions: V1, 1.1
>     Reporter: Carlin Rogers
>     Assignee: Carlin Rogers
>      Fix For: 1.1
>  Attachments: j1029-repro.zip
>
> Multibyte characters are not displayed correctly when the retrievePopupOutput 
>  NetUI tag is used to configure a popup window and flow. The JavaSrcipt 
> written out to the popup window to close the window and pass the map back to 
> the opener window does not have correctly encoded Strings.
> The problem is in the ReturnActionViewRenderer class which writes out the 
> Javascript for the map that is passed back to the opener window. The 
> response.getCharacterEncoding() needs to be set correctly to support the 
> unicode Java String that is to be written out as a value for the map.
> The response for the popup window request in this case is strictly JavaScript 
> to pass a map back to the opener window, and then close the popup window. 
> There is now HTML to display to the user. I think it would be OK in this case 
> to call response.setContentType("text/html; charset=UTF-8") setting the 
> response character encoding to "UTF-8" before we begin writing the javascript 
> and map values.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Reply via email to