Thorsten Berger wrote:
It would break Fusion as it exists today.
A complete patch would include fixes to Fusion as well
Why is that the portal cannot rely on request parameters?
Seems like a very restrictive requirement
Maybe we're talking at crossed purposes.
The character decoding currently implemented does not work correctly
when using (at least) the struts bridge (due to some wrapping of the
ServletRequest).
Could you provide the sample struts bridge code and your
environment info to me? Since I do not encounter problems
on portlets though I did not try it on the struts bridge,
I would like to check the details.
Thanks,
shinsuke
> One possible solution would be to let the servlet
container do the decoding by setting
ServletRequest#setCharacterEncoding() before any
ServletRequest#getParameter() call. Since the
ServletRequest#setCharacterEncoding() is called within the
CapabilitiesValve, I searched for and found two earlier invocations of
getParameter(), which must be removed to make this work.
This change delegates the character decoding, which is currently done in
ServletRequestImpl (and relies on ISO-8859-1 characters), to the servlet
container.
The invocation we're talking about is imho dispensable, as setting
pipelines is done with request attributes (not parameters). Furthermore,
the servlet api does not define a method to set request parameters
programmatically if not transmitted by the browser request. So, is it
really necessary to set the pipeline by a browser request parameter?
e.g.:
http://localhost:8080/jetspeed/?pipeline=test
which of course throws an exception.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------
Know more about Breast Cancer
http://pr.mail.yahoo.co.jp/pinkribbon/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
