You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Ian Boston <ie...@tfd.co.uk> on 2010/01/08 16:31:39 UTC
Request Dispatching.
We have been trying to implement a Batch method processor (ie a servlet that performs multiple requests batching the responses up into a single request/response) in Sling.
Normally with servlets this would require requestDispacher.forward(wrappedRequest, wrappedResponse) but this doent work since Sling unwrapps all request back to a internal SlingHttpServletRequestImpl object so although you can get hold of the requestDispatcher, and call the forward method, its almost pointless.
Whats the right way of doing this sort of thing in Sling ?
Ian
BTW, we have also tried Filters registered against the SlingMainSevlet (via OSGI), adding another top level servlet directly to the httpservice and adding filters at the http service level before the SlingMainServlet. None appear to work for all sorts of reason, sadly perfectly valid and to spec.
Re: Request Dispatching.
Posted by Carsten Ziegeler <cz...@apache.org>.
Alexander Klimetschek wrote
> On Wed, Jul 14, 2010 at 18:02, Carsten Ziegeler <cz...@apache.org> wrote:
>> As already noted I'm not happy with this - this is internal stuff and we
>> should rather leave it the way it is.
>> Why not creating plain http servlet request objects and then going
>> through the sling main servlet?
>
> Interesting, how would you do that? I always thought the request
> dispatcher is meant for this.
>
This depends - if you have already a request, the dispatcher is the way
to go.
But as we are then talking about Sling you propably already have a
Sling request object.
If you don't have a request - and my understand is that we're talking
about this case here - you currently have a problem :) The Sling main
servlet is not registered as a service atm, but we could do this if this
is what we need.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Request Dispatching.
Posted by Alexander Klimetschek <ak...@day.com>.
On Wed, Jul 14, 2010 at 18:02, Carsten Ziegeler <cz...@apache.org> wrote:
> As already noted I'm not happy with this - this is internal stuff and we
> should rather leave it the way it is.
> Why not creating plain http servlet request objects and then going
> through the sling main servlet?
Interesting, how would you do that? I always thought the request
dispatcher is meant for this.
Regards,
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: Request Dispatching.
Posted by Carsten Ziegeler <cz...@apache.org>.
Ian Boston wrote
>
> On 14 Jul 2010, at 16:10, Bertrand Delacretaz wrote:
>
>> On Fri, Jan 8, 2010 at 5:31 PM, Ian Boston <ie...@tfd.co.uk> wrote:
>>> ...We have been trying to implement a Batch method processor (ie a servlet that performs multiple requests batching
>>> the responses up into a single request/response) in Sling.
>>>
>>> Normally with servlets this would require requestDispacher.forward(wrappedRequest, wrappedResponse) but this doent
>>> work since Sling unwrapps all request back to a internal SlingHttpServletRequestImpl object...
>>
>> I'm hitting the same problem in my work on SLING-550, created
>> https://issues.apache.org/jira/browse/SLING-1596 with a suggested
>> patch, also at http://codereview.appspot.com/1783044
>>
>> My solution is not perfect, to be clean I think we'd need to make
>> RequestData a first-class interface instead of an implementation
>> class, but my patch already decreases coupling a bit.
>>
>> Reviews welcome.
>
>
> I have a horrible feeling that if the unwrapped request is not a SlingHttpServletRequestImpl then other parts of the engine misbehave, which may have been the reason for enforcing that. It also allows anything to create a new Request, including scripted components. That may not be desirable.
>
As already noted I'm not happy with this - this is internal stuff and we
should rather leave it the way it is.
Why not creating plain http servlet request objects and then going
through the sling main servlet?
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Request Dispatching.
Posted by Ian Boston <ie...@tfd.co.uk>.
On 15 Jul 2010, at 08:44, Bertrand Delacretaz wrote:
> On Wed, Jul 14, 2010 at 5:51 PM, Ian Boston <ie...@tfd.co.uk> wrote:
>> ...also, did you mean to use tabs, afaik the rest of the code is space based and it can make
>> life hard if the 2 are mixed ?...
>
> Sure, sorry about that, seems like my Eclipse settings got messed up.
> -Bertrand
no problem,
mine too, I upgraded to Helios and lost all the settings,
If you see a commit without a license header (or the wrong one) from me please shout at me.
Ian
Re: Request Dispatching.
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Jul 14, 2010 at 5:51 PM, Ian Boston <ie...@tfd.co.uk> wrote:
> ...also, did you mean to use tabs, afaik the rest of the code is space based and it can make
> life hard if the 2 are mixed ?...
Sure, sorry about that, seems like my Eclipse settings got messed up.
-Bertrand
Re: Request Dispatching.
Posted by Ian Boston <ie...@tfd.co.uk>.
On 14 Jul 2010, at 16:10, Bertrand Delacretaz wrote:
> On Fri, Jan 8, 2010 at 5:31 PM, Ian Boston <ie...@tfd.co.uk> wrote:
>> ...We have been trying to implement a Batch method processor (ie a servlet that performs multiple requests batching
>> the responses up into a single request/response) in Sling.
>>
>> Normally with servlets this would require requestDispacher.forward(wrappedRequest, wrappedResponse) but this doent
>> work since Sling unwrapps all request back to a internal SlingHttpServletRequestImpl object...
>
> I'm hitting the same problem in my work on SLING-550, created
> https://issues.apache.org/jira/browse/SLING-1596 with a suggested
> patch, also at http://codereview.appspot.com/1783044
>
> My solution is not perfect, to be clean I think we'd need to make
> RequestData a first-class interface instead of an implementation
> class, but my patch already decreases coupling a bit.
>
> Reviews welcome.
I have a horrible feeling that if the unwrapped request is not a SlingHttpServletRequestImpl then other parts of the engine misbehave, which may have been the reason for enforcing that. It also allows anything to create a new Request, including scripted components. That may not be desirable.
However, if thats ok, then the patch looks good to me.
I think we abandoned dynamic re-dispatch in favour of static binding to paths or explicit service calls.
also, did you mean to use tabs, afaik the rest of the code is space based and it can make life hard if the 2 are mixed ?
Ian
> -Bertrand
Re: Request Dispatching.
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Fri, Jan 8, 2010 at 5:31 PM, Ian Boston <ie...@tfd.co.uk> wrote:
> ...We have been trying to implement a Batch method processor (ie a servlet that performs multiple requests batching
> the responses up into a single request/response) in Sling.
>
> Normally with servlets this would require requestDispacher.forward(wrappedRequest, wrappedResponse) but this doent
> work since Sling unwrapps all request back to a internal SlingHttpServletRequestImpl object...
I'm hitting the same problem in my work on SLING-550, created
https://issues.apache.org/jira/browse/SLING-1596 with a suggested
patch, also at http://codereview.appspot.com/1783044
My solution is not perfect, to be clean I think we'd need to make
RequestData a first-class interface instead of an implementation
class, but my patch already decreases coupling a bit.
Reviews welcome.
-Bertrand
Re: Request Dispatching.
Posted by Vidar Ramdal <vi...@idium.no>.
On Mon, Jan 11, 2010 at 6:07 PM, Ray Davis <ra...@media.berkeley.edu> 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.
I have also gone down that road once or twice, trying to modify
request parameters before forwarding a request to another servlet.
However, I find that I usually can achieve what I want by implementing
a SlingPostProcessor. The SlingPostServlet does not persist any data
before the PostProcessors are run, so I'm able to modify/revert any
operations here.
--
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Sommerrogata 13-15, N-0255 Oslo, Norway
+ 47 22 00 84 00 / +47 21 531941, ext 2070
Re: Request Dispatching.
Posted by Simon Gaeremynck <ga...@gmail.com>.
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
>>
Re: Request Dispatching.
Posted by Felix Meschberger <fm...@gmail.com>.
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
>
Re: Request Dispatching.
Posted by Ray Davis <ra...@media.berkeley.edu>.
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.
That seemed to block some of the intended functionality of
SlingHttpServletRequestWrapper. But, as I say, I didn't pursue the question.
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
Re: Request Dispatching.
Posted by Felix Meschberger <fm...@gmail.com>.
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
>
> Best,
> Ray
>
> On 1/8/10 7:31 AM, Ian Boston wrote:
>> We have been trying to implement a Batch method processor (ie a
>> servlet that performs multiple requests batching the responses up into
>> a single request/response) in Sling.
>>
>> Normally with servlets this would require
>> requestDispacher.forward(wrappedRequest, wrappedResponse) but this
>> doent work since Sling unwrapps all request back to a internal
>> SlingHttpServletRequestImpl object so although you can get hold of the
>> requestDispatcher, and call the forward method, its almost pointless.
>>
>> Whats the right way of doing this sort of thing in Sling ?
>>
>> Ian
>>
>> BTW, we have also tried Filters registered against the SlingMainSevlet
>> (via OSGI), adding another top level servlet directly to the
>> httpservice and adding filters at the http service level before the
>> SlingMainServlet. None appear to work for all sorts of reason, sadly
>> perfectly valid and to spec.
>
>
Re: Request Dispatching.
Posted by Ray Davis <ra...@media.berkeley.edu>.
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.
Best,
Ray
On 1/8/10 7:31 AM, Ian Boston wrote:
> We have been trying to implement a Batch method processor (ie a servlet that performs multiple requests batching the responses up into a single request/response) in Sling.
>
> Normally with servlets this would require requestDispacher.forward(wrappedRequest, wrappedResponse) but this doent work since Sling unwrapps all request back to a internal SlingHttpServletRequestImpl object so although you can get hold of the requestDispatcher, and call the forward method, its almost pointless.
>
> Whats the right way of doing this sort of thing in Sling ?
>
> Ian
>
> BTW, we have also tried Filters registered against the SlingMainSevlet (via OSGI), adding another top level servlet directly to the httpservice and adding filters at the http service level before the SlingMainServlet. None appear to work for all sorts of reason, sadly perfectly valid and to spec.
Re: Request Dispatching.
Posted by Ray Davis <ra...@media.berkeley.edu>.
In other words, What Ian Said. :)
Best,
Ray
On 1/11/10 12:36 PM, Ian Boston wrote:
>
> On 11 Jan 2010, at 19:43, Felix Meschberger wrote:
>
>>
>>
>> On 08.01.2010 16:31, Ian Boston wrote:
>>> We have been trying to implement a Batch method processor (ie a servlet that performs multiple requests batching the responses up into a single request/response) in Sling.
>>>
>>> Normally with servlets this would require requestDispacher.forward(wrappedRequest, wrappedResponse) but this doent work since Sling unwrapps all request back to a internal SlingHttpServletRequestImpl object so although you can get hold of the requestDispatcher, and call the forward method, its almost pointless.
>>
>> I fear, I do not completely understand the problem.
>>
>> You can provide any SlingHttpServletRequest|Response to the forward
>> method and this instance will be presented to the included servlet.
>>
>> If not the provided instances are given to the included servlet, I would
>> consider this a major issue....
>>
>>>
>>> Whats the right way of doing this sort of thing in Sling ?
>>
>> I would say that it should be possible to forward multiple times
>> collecting the output -- you would just have to make sure, no output and
>> headers are really written back by the servlets/scripts forwarded to.
>> Thus the wrappedResponse would have to make sure not to set responses
>> headers (by default in Sling included servlets *can* set response
>> headers unlike in the Servlet API, where this is not possible).
>
> Wrapping the response works perfectly,
>
> Wrapping the request does not.
>
> The SlingRequestDispatcher uses the RequestData.unwrap(...) to unwrap any request back to the first SlingHttpServletRequestImpl (private to the engine bundle) effectively negating any attempt to wrap the request object.
>
> Perhaps there should be a marker interface to identify when its safe to use a request object and when it needs to be unwrapped further.
>
> Ian
>
>
>>
>> Regards
>> Felix
>>
>>>
>>> Ian
>>>
>>> BTW, we have also tried Filters registered against the SlingMainSevlet (via OSGI), adding another top level servlet directly to the httpservice and adding filters at the http service level before the SlingMainServlet. None appear to work for all sorts of reason, sadly perfectly valid and to spec.
>
>
Re: Request Dispatching.
Posted by Ian Boston <ie...@tfd.co.uk>.
On 11 Jan 2010, at 20:59, Felix Meschberger wrote:
> Hi,
>
> On 11.01.2010 21:36, Ian Boston wrote:
>>
>> On 11 Jan 2010, at 19:43, Felix Meschberger wrote:
>>
>>>
>>>
>>> On 08.01.2010 16:31, Ian Boston wrote:
>>>> We have been trying to implement a Batch method processor (ie a servlet that performs multiple requests batching the responses up into a single request/response) in Sling.
>>>>
>>>> Normally with servlets this would require requestDispacher.forward(wrappedRequest, wrappedResponse) but this doent work since Sling unwrapps all request back to a internal SlingHttpServletRequestImpl object so although you can get hold of the requestDispatcher, and call the forward method, its almost pointless.
>>>
>>> I fear, I do not completely understand the problem.
>>>
>>> You can provide any SlingHttpServletRequest|Response to the forward
>>> method and this instance will be presented to the included servlet.
>>>
>>> If not the provided instances are given to the included servlet, I would
>>> consider this a major issue....
>>>
>>>>
>>>> Whats the right way of doing this sort of thing in Sling ?
>>>
>>> I would say that it should be possible to forward multiple times
>>> collecting the output -- you would just have to make sure, no output and
>>> headers are really written back by the servlets/scripts forwarded to.
>>> Thus the wrappedResponse would have to make sure not to set responses
>>> headers (by default in Sling included servlets *can* set response
>>> headers unlike in the Servlet API, where this is not possible).
>>
>> Wrapping the response works perfectly,
>>
>> Wrapping the request does not.
>>
>> The SlingRequestDispatcher uses the RequestData.unwrap(...) to unwrap any request back to the first SlingHttpServletRequestImpl (private to the engine bundle) effectively negating any attempt to wrap the request object.
>
> I am not sure, whether we are referring to the same code ...
>
> The SlingRequestDispatcher.dispatch method does:
>
> SlingHttpServletRequest cRequest = RequestData.unwrap(request);
>
> which returns a SlingHttpServletRequest from the request, which is a
> ServletRequest.
>
> Now the RequestData.unwrap(ServletRequest method) does :
>
> // this should be triggered and immediately return if the
> // request is a SlingHttpServletRequestWrapper or
> // a SlingHttpServletRequestImpl object
> if (request instanceof SlingHttpServletRequest) {
> return (SlingHttpServletRequest) request;
> }
>
> // unwrap wrappers
> while (request instanceof ServletRequestWrapper) {
> request = ((ServletRequestWrapper) request).getRequest();
>
> // immediate termination if we found one
> if (request instanceof SlingHttpServletRequest) {
> return (SlingHttpServletRequest) request;
> }
> }
>
> according to my reading, this should returns topmost
> SlingHttpServletRequest object, in general is the request object itself.
>
> If there is a misconception on my part, I would be happy to be standing
> corrected !
>
> The intent is to *not* unwrap down to the innermost
> SlingHttpServletRequestImpl and use that.
I might have got the start of the call stack wrong but
its the other unwrap method that causes the problem.
I stepped through it in a debugger a few days ago and I think the important call stack started when the request was converted into RequestData from which the request parameters are taken.
I think
SlingMainServlet.processRequest()
RequestData.service( ) line 493
RequestData.getRequestData() line 400
RequestData.unwrap() line 314
That goes back to the impl,
The servlet is than taken from that request data, so any attempt to re-dispatch to a new path will bind to the old RequestData.
to exactly what happens when a
request.getRequestDispatcher(path).forward(wrappedRequest, wrappedResponse)
is invoked I will need to re-run a debug session, probably best to hold on.
Ian
>
> Regards
> Felix
>
>>
>> Perhaps there should be a marker interface to identify when its safe to use a request object and when it needs to be unwrapped further.
>>
>> Ian
>>
>>
>>>
>>> Regards
>>> Felix
>>>
>>>>
>>>> Ian
>>>>
>>>> BTW, we have also tried Filters registered against the SlingMainSevlet (via OSGI), adding another top level servlet directly to the httpservice and adding filters at the http service level before the SlingMainServlet. None appear to work for all sorts of reason, sadly perfectly valid and to spec.
>>
>>
Re: Request Dispatching.
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
On 11.01.2010 21:36, Ian Boston wrote:
>
> On 11 Jan 2010, at 19:43, Felix Meschberger wrote:
>
>>
>>
>> On 08.01.2010 16:31, Ian Boston wrote:
>>> We have been trying to implement a Batch method processor (ie a servlet that performs multiple requests batching the responses up into a single request/response) in Sling.
>>>
>>> Normally with servlets this would require requestDispacher.forward(wrappedRequest, wrappedResponse) but this doent work since Sling unwrapps all request back to a internal SlingHttpServletRequestImpl object so although you can get hold of the requestDispatcher, and call the forward method, its almost pointless.
>>
>> I fear, I do not completely understand the problem.
>>
>> You can provide any SlingHttpServletRequest|Response to the forward
>> method and this instance will be presented to the included servlet.
>>
>> If not the provided instances are given to the included servlet, I would
>> consider this a major issue....
>>
>>>
>>> Whats the right way of doing this sort of thing in Sling ?
>>
>> I would say that it should be possible to forward multiple times
>> collecting the output -- you would just have to make sure, no output and
>> headers are really written back by the servlets/scripts forwarded to.
>> Thus the wrappedResponse would have to make sure not to set responses
>> headers (by default in Sling included servlets *can* set response
>> headers unlike in the Servlet API, where this is not possible).
>
> Wrapping the response works perfectly,
>
> Wrapping the request does not.
>
> The SlingRequestDispatcher uses the RequestData.unwrap(...) to unwrap any request back to the first SlingHttpServletRequestImpl (private to the engine bundle) effectively negating any attempt to wrap the request object.
I am not sure, whether we are referring to the same code ...
The SlingRequestDispatcher.dispatch method does:
SlingHttpServletRequest cRequest = RequestData.unwrap(request);
which returns a SlingHttpServletRequest from the request, which is a
ServletRequest.
Now the RequestData.unwrap(ServletRequest method) does :
// this should be triggered and immediately return if the
// request is a SlingHttpServletRequestWrapper or
// a SlingHttpServletRequestImpl object
if (request instanceof SlingHttpServletRequest) {
return (SlingHttpServletRequest) request;
}
// unwrap wrappers
while (request instanceof ServletRequestWrapper) {
request = ((ServletRequestWrapper) request).getRequest();
// immediate termination if we found one
if (request instanceof SlingHttpServletRequest) {
return (SlingHttpServletRequest) request;
}
}
according to my reading, this should returns topmost
SlingHttpServletRequest object, in general is the request object itself.
If there is a misconception on my part, I would be happy to be standing
corrected !
The intent is to *not* unwrap down to the innermost
SlingHttpServletRequestImpl and use that.
Regards
Felix
>
> Perhaps there should be a marker interface to identify when its safe to use a request object and when it needs to be unwrapped further.
>
> Ian
>
>
>>
>> Regards
>> Felix
>>
>>>
>>> Ian
>>>
>>> BTW, we have also tried Filters registered against the SlingMainSevlet (via OSGI), adding another top level servlet directly to the httpservice and adding filters at the http service level before the SlingMainServlet. None appear to work for all sorts of reason, sadly perfectly valid and to spec.
>
>
Re: Request Dispatching.
Posted by Ian Boston <ie...@tfd.co.uk>.
On 11 Jan 2010, at 19:43, Felix Meschberger wrote:
>
>
> On 08.01.2010 16:31, Ian Boston wrote:
>> We have been trying to implement a Batch method processor (ie a servlet that performs multiple requests batching the responses up into a single request/response) in Sling.
>>
>> Normally with servlets this would require requestDispacher.forward(wrappedRequest, wrappedResponse) but this doent work since Sling unwrapps all request back to a internal SlingHttpServletRequestImpl object so although you can get hold of the requestDispatcher, and call the forward method, its almost pointless.
>
> I fear, I do not completely understand the problem.
>
> You can provide any SlingHttpServletRequest|Response to the forward
> method and this instance will be presented to the included servlet.
>
> If not the provided instances are given to the included servlet, I would
> consider this a major issue....
>
>>
>> Whats the right way of doing this sort of thing in Sling ?
>
> I would say that it should be possible to forward multiple times
> collecting the output -- you would just have to make sure, no output and
> headers are really written back by the servlets/scripts forwarded to.
> Thus the wrappedResponse would have to make sure not to set responses
> headers (by default in Sling included servlets *can* set response
> headers unlike in the Servlet API, where this is not possible).
Wrapping the response works perfectly,
Wrapping the request does not.
The SlingRequestDispatcher uses the RequestData.unwrap(...) to unwrap any request back to the first SlingHttpServletRequestImpl (private to the engine bundle) effectively negating any attempt to wrap the request object.
Perhaps there should be a marker interface to identify when its safe to use a request object and when it needs to be unwrapped further.
Ian
>
> Regards
> Felix
>
>>
>> Ian
>>
>> BTW, we have also tried Filters registered against the SlingMainSevlet (via OSGI), adding another top level servlet directly to the httpservice and adding filters at the http service level before the SlingMainServlet. None appear to work for all sorts of reason, sadly perfectly valid and to spec.
Re: Request Dispatching.
Posted by Felix Meschberger <fm...@gmail.com>.
On 08.01.2010 16:31, Ian Boston wrote:
> We have been trying to implement a Batch method processor (ie a servlet that performs multiple requests batching the responses up into a single request/response) in Sling.
>
> Normally with servlets this would require requestDispacher.forward(wrappedRequest, wrappedResponse) but this doent work since Sling unwrapps all request back to a internal SlingHttpServletRequestImpl object so although you can get hold of the requestDispatcher, and call the forward method, its almost pointless.
I fear, I do not completely understand the problem.
You can provide any SlingHttpServletRequest|Response to the forward
method and this instance will be presented to the included servlet.
If not the provided instances are given to the included servlet, I would
consider this a major issue....
>
> Whats the right way of doing this sort of thing in Sling ?
I would say that it should be possible to forward multiple times
collecting the output -- you would just have to make sure, no output and
headers are really written back by the servlets/scripts forwarded to.
Thus the wrappedResponse would have to make sure not to set responses
headers (by default in Sling included servlets *can* set response
headers unlike in the Servlet API, where this is not possible).
Regards
Felix
>
> Ian
>
> BTW, we have also tried Filters registered against the SlingMainSevlet (via OSGI), adding another top level servlet directly to the httpservice and adding filters at the http service level before the SlingMainServlet. None appear to work for all sorts of reason, sadly perfectly valid and to spec.