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 >
