[ http://issues.apache.org/jira/browse/JS2-376?page=comments#action_12331705 ]
Shinsuke SUGAYA commented on JS2-376: ------------------------------------- I'll check the patch and this issue.. > request parameter encoding problem > ---------------------------------- > > Key: JS2-376 > URL: http://issues.apache.org/jira/browse/JS2-376 > Project: Jetspeed 2 > Type: Bug > Components: Components Core > Versions: 2.0-M4 > Reporter: Thorsten Berger > Attachments: j2_character_encoding_jira376.txt > > I logged an issue for the struts bridge, but found out that this problem is > specific to jetspeed. > Please see PB-14 (unable to post unicode characters in struts bridge) for an > introduction. > The problem is the character decoding done in in > o.a.j.engine.servlet.ServletRequestImpl (line 157): > try > { > paramValues[i] = new > String(paramValues[i].getBytes("ISO-8859-1"), getCharacterEncoding()); > } > catch (UnsupportedEncodingException e) > > The struts bridge now does some further wrapping of the ServletRequest > resulting in calling the code above twice (and decoding decoded parameter > strings again). It's clear that this results in garbage characters. > The first call is done by jetspeed itself (providing parameters to the > StrutsPortlet) and the second by the Struts RequestProcessor (to populate the > form bean). However, I think this behaviour should be changed in Jetspeed. > I'd like to suggest two solutions: > 1: setting a request attribute indicating that request parameters have > already been decoded, which prevents the second decoding > 2: Delegating the decoding to the servlet api. (my preferred solution) > I think hard-coding the encoding is unclean. The portal cannot count on > "ISO-8859-1" parameter strings (which is especially true in the above case). > The delegation could be achieved by: > - removing the decoding from o.a.j.engine.servlet.ServletRequestImpl > - changing JetspeedRequestContext.setCharacterEncoding() to set the encoding > also to the wrapped HttpServletRequest > - as you know this has to be done before the first getParameter() call is > invoked, the following two calls must be removed to make this work: > line 60 in CapabilityValveImpl (the variable "requestMediaType" is never > used) and line 192 in JetspeedEngine (noticed that "targetPipeline" is never > set as request parameter rather than as request attribute) > -> results in the CapabilityValveImpl setting the characterEncoding before > any getParameter() call > As I urgently need this to work for my portal I applied solution 2. I would > provide a patch for this solution if you're in agreement. > Regards, Thorsten -- 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
