Yes, the forwarding happens correctly but the generating of the
RequestParameters
is al internal to sling.
So if somebody wants to forward a request with different parameters it
is not
enough to just override the regular servlet parameters.
You also have to implement the RequestParameter, RequestParamaterMap
interfaces and all the parameter related issues
that Sling takes care of (ex: _charset_, encoding ..)
Simon
On 11 Jan 2010, at 21:06, Felix Meschberger wrote:
Hi,
On 11.01.2010 21:53, Ray Davis wrote:
It's been a while, so this might be out-of-date, or I might have
misunderstood the intent. Here's what seemed to be happening:
Assuming that SlingHttpServletRequestWrapper was intended to be used
like HttpServletRequestWrapper, I subclassed it to override some
relevant "get" methods. But before those overrides could come into
play,
SlingMainServlet triggered a call to RequestData's "unwrap" method,
which discarded all layers of wrapper so as to go straight through
to an
instance of SlingHttpServletRequestImpl.
I think the current state of the SlingRequestDispatcher in the Engine
bundle does not do that and correctly uses the provided request.
That seemed to block some of the intended functionality of
SlingHttpServletRequestWrapper. But, as I say, I didn't pursue the
question.
It may well be that some time ago, this was wrong.
Regards
Felix
Best,
Ray
Felix Meschberger wrote:
Hi,
On 11.01.2010 18:07, Ray Davis wrote:
FWIW, as a Sling newcomer I got tripped up by the same code in
Sling's
RequestData class when I tried to mix in some request parameters
in the
usual way. This seemed to put a sizable dent in the usefulness of
SlingHttpServletRequestWrapper, but I didn't have time to pursue
the
matter then.
What is the exact use case you didn't succeed in implementing ?
This sounds very much like a bug.
Regards
Felix
