You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Vadim Dmitriev (JIRA)" <de...@myfaces.apache.org> on 2008/05/13 00:56:55 UTC
[jira] Created: (TRINIDAD-1073) Character encoding problem with PPR
on IBM WebSphere 6.0
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.
Re: [jira] Commented: (TRINIDAD-1073) Character encoding problem
with PPR on IBM WebSphere 6.0
Posted by Paul Mander <pa...@gmail.com>.
My Faces - Dev mailing list wrote:
>
>
> [
> https://issues.apache.org/jira/browse/TRINIDAD-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12864852#action_12864852
> ]
>
> Vadim Dmitriev commented on TRINIDAD-1073:
> ------------------------------------------
>
> ExternalContext mainly just delegates calls to the underlying context
> (PortletContext, ServletContext). ServletContext is provided by the
> container and will be different for Tomcat, WebSphere, WebLogic, etc. Real
> difference in client request processing lies there.
> I doubt it is possible to force application server to use custom servlet
> implementation, especially closed-source commercial appserver.
>
>> 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.
>
>
>
It's looking like IBM are going to wash their hands on this one. Can anyone
help on this one?
--
View this message in context: http://old.nabble.com/-jira--Created%3A-%28TRINIDAD-1073%29-Character-encoding-problem-with-PPR-on-IBM-WebSphere-6.0-tp17197824p28597227.html
Sent from the My Faces - Dev mailing list archive at Nabble.com.
Re: [jira] Commented: (TRINIDAD-1073) Character encoding problem
with PPR on IBM WebSphere 6.0
Posted by Paul Mander <pa...@gmail.com>.
Paul Mander wrote:
>
> Just to follow up on this, there is a post
> http://old.nabble.com/-Trinidad--forced-UTF-8-in-PPR-responses--ts27545426.html#a27545426
> that 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.
>
and updating the XmlHttpServletRequest to set encoding to iso-8859-1 has no
impact. The corruption appears to be on the request rather than the response
- debugging the setter of the inputtext shows "?" for a ppr request, but
fine for a full submit
--
View this message in context: http://old.nabble.com/-jira--Created%3A-%28TRINIDAD-1073%29-Character-encoding-problem-with-PPR-on-IBM-WebSphere-6.0-tp17197824p28459799.html
Sent from the My Faces - Dev mailing list archive at Nabble.com.
Re: [jira] Commented: (TRINIDAD-1073) Character encoding problem
with PPR on IBM WebSphere 6.0
Posted by Paul Mander <pa...@gmail.com>.
I'm seeing this issue on WebSphere 6.1 and Trinidad 1.0.11. Trinidad-1430
addressed part of this issue (in 1.0.12) but not totally. If I do a PPR on
an input text that contains cyrillic characters, they are replaced by "?".
Just to follow up on this, there is a post
http://old.nabble.com/-Trinidad--forced-UTF-8-in-PPR-responses--ts27545426.html#a27545426
that 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.
--
View this message in context: http://old.nabble.com/-jira--Created%3A-%28TRINIDAD-1073%29-Character-encoding-problem-with-PPR-on-IBM-WebSphere-6.0-tp17197824p28459402.html
Sent from the My Faces - Dev mailing list archive at Nabble.com.
Re: [jira] Commented: (TRINIDAD-1073) Character encoding problem
with PPR on IBM WebSphere 6.0
Posted by Paul Mander <pa...@gmail.com>.
My Faces - Dev mailing list wrote:
>
>
> [
> https://issues.apache.org/jira/browse/TRINIDAD-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12627707#action_12627707
> ]
>
> Matthias Weßendorf commented on TRINIDAD-1073:
> ----------------------------------------------
>
> any chance that there is an extra filter that queries the request params
> before the ExternalCtx implementation actually set the encoding ?
> What does your app do on Tomcat (I don't have WebSphere)
>
>> 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.
>
>
>
I'm seeing this issue on WebSphere 6.1 and Trinidad 1.0.11. Trinidad-1430
addressed part of this issue (in 1.0.12) but not totally. If I do a PPR on
an input text that contains cyrillic characters, they are replaced by "?".
--
View this message in context: http://old.nabble.com/-jira--Created%3A-%28TRINIDAD-1073%29-Character-encoding-problem-with-PPR-on-IBM-WebSphere-6.0-tp17197824p28459120.html
Sent from the My Faces - Dev mailing list archive at Nabble.com.
[jira] Commented: (TRINIDAD-1073) Character encoding problem with
PPR on IBM WebSphere 6.0
Posted by "Vadim Dmitriev (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12864852#action_12864852 ]
Vadim Dmitriev commented on TRINIDAD-1073:
------------------------------------------
ExternalContext mainly just delegates calls to the underlying context (PortletContext, ServletContext). ServletContext is provided by the container and will be different for Tomcat, WebSphere, WebLogic, etc. Real difference in client request processing lies there.
I doubt it is possible to force application server to use custom servlet implementation, especially closed-source commercial appserver.
> 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.
[jira] Issue Comment Edited: (TRINIDAD-1073) Character encoding
problem with PPR on IBM WebSphere 6.0
Posted by "Paul Mander (JIRA)" <de...@myfaces.apache.org>.
[ 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.
[jira] Commented: (TRINIDAD-1073) Character encoding problem with
PPR on IBM WebSphere 6.0
Posted by "Paul Mander (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12864301#action_12864301 ]
Paul Mander commented on TRINIDAD-1073:
---------------------------------------
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.
> 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.
[jira] Commented: (TRINIDAD-1073) Character encoding problem with
PPR on IBM WebSphere 6.0
Posted by "Matthias Weßendorf (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12627707#action_12627707 ]
Matthias Weßendorf commented on TRINIDAD-1073:
----------------------------------------------
any chance that there is an extra filter that queries the request params before the ExternalCtx implementation actually set the encoding ?
What does your app do on Tomcat (I don't have WebSphere)
> 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.
[jira] Commented: (TRINIDAD-1073) Character encoding problem with
PPR on IBM WebSphere 6.0
Posted by "Paul Mander (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12873948#action_12873948 ]
Paul Mander commented on TRINIDAD-1073:
---------------------------------------
Thanks Naveen,
You posted an alternative solution also that reduces the amount of parsing by just addressing the text input contents. I've included this here for completeness:
In XMLRequest.js
TrRequestQueue.prototype._getPostbackContent = function(actionForm, params)
current.push(input.value);
}
else
{
//FIX:start
// encoding only characters entered in text box
if(input.type == "text"){
formParams[input.name] = encodeCharacters(input.value);
}else{
//FIX:end
formParams[input.name] = input.value;
//FIX:start
}
//FIX:start
}
This addresses any performance issues with javascript string concatination: http://www.softwaresecretweapons.com/jspwiki/javascriptstringconcatenation
However, I don't think this fix can be accepted by Trinidad as it subsequently breaks all the other app servers that appear to be working ok. I still think this is a WebSphere issue even though they refuse to fix it. But unfortunately we wont be able to tell from the js what the app server is unless we either have a configuration setting or there is some conditional includes based on the app server vendor and version (as this will likely be a problem only in WAS 6.x)
> 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.
[jira] Issue Comment Edited: (TRINIDAD-1073) Character encoding
problem with PPR on IBM WebSphere 6.0
Posted by "Paul Mander (JIRA)" <de...@myfaces.apache.org>.
[ 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/5/10 11:17 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 "?".
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'll attempt to find out the differences in these environments.
> 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.
[jira] Commented: (TRINIDAD-1073) Character encoding problem with
PPR on IBM WebSphere 6.0
Posted by "Naveen Ravindra (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12872188#action_12872188 ]
Naveen Ravindra commented on TRINIDAD-1073:
-------------------------------------------
Hello All,
This issue is observed with Websphere-Trinidad stack.
A resolution for this issue is to encode the special characters before POST request. If the method is POST and the data passed to the send() is a string, the data MUST be encoded as UTF-8 for transmission.
You need to modify file XMLRequest.js found under
1. trinidad-impl-XXX.jar\META-INF\adf\jsLibsDebug\xhr
2. trinidad-impl-XXX.jar\META-INF\adf\jsLibs\xhr
The file which would be downloaded depends on the mode configured in web.xml
<context-param>
<description>
Apache Trinidad by default obfuscates the Javascript it delivers to the client, as well as stripping comments and whitespace. This dramatically reduces the size of our Javascript download, but also makes it tricky to debug the Javascript. This flag can be set to true to turn off the obfuscation.
Always set to false in a production environment.
</description>
<param-name>org.apache.myfaces.trinidad.DEBUG_JAVASCRIPT</param-name>
<param-value>true</param-value>
</context-param>
Below are the changes required:
1. Add the below function to XMLRequest.js
function encodeCharacters(string) {
string = string.replace(/\r\n/g,"\n");
var utftext = "";
for (var n = 0; n < string.length; n++) {
var c = string.charCodeAt(n);
if (c < 128) {
utftext += String.fromCharCode(c);
}
else if((c > 127) && (c < 2048)) {
utftext += String.fromCharCode((c >> 6) | 192);
utftext += String.fromCharCode((c & 63) | 128);
}
else {
utftext += String.fromCharCode((c >> 12) | 224);
utftext += String.fromCharCode(((c >> 6) & 63) | 128);
utftext += String.fromCharCode((c & 63) | 128);
}
}
return utftext;
}
2. In TrXMLRequest.prototype.send related function change xmlhttp.send(content); to xmlhttp.send(encodeCharacters(content));
Make sure you clear the temporary Internet files before evaluating the resolution.
Regards,
Naveen
> 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.
[jira] Issue Comment Edited: (TRINIDAD-1073) Character encoding
problem with PPR on IBM WebSphere 6.0
Posted by "Paul Mander (JIRA)" <de...@myfaces.apache.org>.
[ 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/5/10 10:50 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'll attempt to find out the differences in these environments.
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.
> 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.