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). 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]
