[ http://issues.apache.org/jira/browse/JS2-376?page=all ]
Thorsten Berger updated JS2-376:
--------------------------------
Attachment: j2_character_encoding_jira376.txt
Patch attached for solution 2.
I could also provide a patch for solution 1, which would be much easier to
implement.
But, as I'm still trying to get the big picture, maybe someone has a better
suggestion of how to resolve this issue.
Regards, Thorsten
> 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]
