Re: [jetty-users] Threading model (was Re: Jetty 12 schedule?_

["Cantor, Scott" <cantor.2@xxxxxxx>]

>    The assumption that you'll be passed a HttpServletRequest and/or
> HttpServletResponse to these actions isn't 100% true.

Ok, I can see that.

>    Take for example the Async I/O events.

Which we will never, ever call/use/allow.

>    There are similar things elsewhere in the spec.

Most of them are in the same bucket, we don't do that kind of thing.

>  Keep in mind that there is no provision in the Servlet spec for notifying
> of the lifecycle of the HttpServletRequest or HttpServletResponse
> objects.

Understood, but they have to exist for the lifetime of the call to the servlet dispatch method, absent use of other container services that interrupt the processing chain of that method, no? Otherwise it's madness since we couldn't even make it work by passing them around if we wanted to.

>    The proper way is to use the request / response objects as passed to
> you, and not hold onto them.

That would imply that one has to immediate extract every possible bit from them and construct a new façade for the data before one's servlet method even calls another object. That's a pretty huge step backward, if true.

> As a servlet endpoint, you are expected to get what you need from the
> request (headers, body, etc), formulate a response (status code,
> headers, etc) and then produce a body.

Of course, but that is never (outside trivial samples) one class. It's a chain of many objects and methods doing work. You don't pass the interfaces into every method.

And even if you did pass them into every method in a synchronous call chain, you're implying that wouldn't even help. And that seems impossible since I can't even see how you would ever be in the middle of the code to interfere with it.

Again, there is no use of async anything whatsoever (once we get control), and there never will be. For exactly this reason.

>    If you need to track things between dispatches of the same exchange,
> it's usually a good idea to use the request attributes to hold onto objects
> for the scope of that one request.

If I have no HttpServletRequest, how would I possibly put or get them? That doesn't change the situation, really.

>    Don't forget about normal redispatch behavior.

That's worth more study, especially the error case, but that's likely past the point we'd be doing anything unusual depending on these interfaces. But it is a point we need to consider.

>    Imagine if the APIs contained the request/response objects
> everywhere, which ones do we give you if wrapping occurs? (eg: if a
> Filter wrapped the request, and added the listener, then the Servlet
> wrapped again, and then that listener needed to fire, do we give you the
> servlet wrapped request or the filter wrapped request?)

Yes, I can see why they had to do things the way they did for the Async APIs. Which we don't use.

-- Scott