[
https://issues.apache.org/jira/browse/TRINIDAD-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12864301#action_12864301
]
Paul Mander edited comment on TRINIDAD-1073 at 5/6/10 6:35 AM:
---------------------------------------------------------------
The post
http://old.nabble.com/-Trinidad--forced-UTF-8-in-PPR-responses--ts27545426.html#a27545426
questions the validity of code in XmlHttpServletResponse. I see that in my
test case, the original encoding "ISO-8859-1" is replaced by utf-8 but if I
amend this code to use the original encoding, the issue still occurs.
The corruption appears to be on the request rather than the response -
debugging the setter of my inputtext shows "?" for a ppr request, but fine for
a full submit and updating the XmlHttpServletRequest to set encoding to
iso-8859-1 has no impact.
I have tested this with Trinidad 1.0.11 on WAS 6.1. on Trinidad 1.2.10 (myfaces
1.2.5) running on tomcat 6, this issue does not occur.
I have also tested now with Trinidad 1.0.11 on Tomcat 6 (ie8 ff3 op10 chrome3)
and the issue does not occur which points the finger firmly at websphere.
There was a comment the Matthias that suggested a websphere filter could be
checking request parameters before the trinidad filter. This could be the case
however, the corruption of the cyrillic characters is different to the case
where a filter sets the encoding. In that scenario, the cyrillic characters
appear top be replaced by 2 other characters and not "?".
On further investigation of the WebSphere 6.1 and Tomcat environments I see One
difference that could be contributing to this issue. The external context that
faces uses is different per environment. The object that represents the servlet
context is as follows
WebSphere: com.sun.faces.context.ExternalContextImpl
Tomcat: org.apache.myfaces.context.servlet.ServletExternalContextImpl
This is odd given that both wars have the exact same composition and the
WebSphere war is configured to use its own classes first before using any
websphere classes. Now, websphere comes with its own JSF implementation which I
think is providing the servlet context implementation. If we can somehow force
websphere to use the same servlet context impl as tomcat, then the decoding may
function correctly.
was (Author: pmander):
The post
http://old.nabble.com/-Trinidad--forced-UTF-8-in-PPR-responses--ts27545426.html#a27545426
questions the validity of code in XmlHttpServletResponse. I see that in my
test case, the original encoding "ISO-8859-1" is replaced by utf-8 but if I
amend this code to use the original encoding, the issue still occurs.
The corruption appears to be on the request rather than the response -
debugging the setter of my inputtext shows "?" for a ppr request, but fine for
a full submit and updating the XmlHttpServletRequest to set encoding to
iso-8859-1 has no impact.
I have tested this with Trinidad 1.0.11 on WAS 6.1. on Trinidad 1.2.10 (myfaces
1.2.5) running on tomcat 6, this issue does not occur.
I have also tested now with Trinidad 1.0.11 on Tomcat 6 (ie8 ff3 op10 chrome3)
and the issue does not occur which points the finger firmly at websphere.
There was a comment the Matthias that suggested a websphere filter could be
checking request parameters before the trinidad filter. This could be the case
however, the corruption of the cyrillic characters is different to the case
where a filter sets the encoding. In that scenario, the cyrillic characters
appear top be replaced by 2 other characters and not "?".
> Character encoding problem with PPR on IBM WebSphere 6.0
> --------------------------------------------------------
>
> Key: TRINIDAD-1073
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1073
> Project: MyFaces Trinidad
> Issue Type: Bug
> Affects Versions: 1.0.7-core
> Environment: MyFaces 1.1.5
> IBM WebSphere 6.0
> Windows XP SP2
> Reporter: Vadim Dmitriev
>
> Input fields updated via PPR replace cyrillic characters with question marks.
> There is no encoding problems if update is performed with ordinary form
> submit.
> Simple testcase:
> create JSF page with tr:showDetailHeader containing tr:inputText. Type some
> cyrillic characters in the input field. Close/open detailheader. As a result
> cyrillic chars in the inputText will be replaced with question marks.
> There is no problem with encoding whatsoever if that showDetailHeader is
> updated by ordinary update (navigation from/to that page, for example).
> This problem is specific to WebSphere 6.0 (maybe 6.1 too, never had a chance
> to check it). I tried the same testcase on OC4J 10.3.3.2 and everything went
> fine.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
