> It's a general anti-pattern to hold onto, use, reference a
> HttpServletRequest or HttpServletResponse object outside of the
> dispatch from the container.
One more question about this I guess...
Is it fair to assume that the only way a request could possibly cross threads
like that is if there's also an actually explicit entry point into one's
application logic by which the container is actually invoking a standard
interface that is defined to accept the HttpServletRequest/Response?
In other words, I take your point that people can build code that leverages
various advanced async/etc. features in the servlet spec, and we don't
necessarily know that's happening, but it has to *be* some explicit invocation
of a container technology that in turn is going to call back in with the
"proper" servlet request/response, right?
Otherwise how could one ever know which instance of the request/response
interfaces to act on?
All we do is implement servlets (or make use of them) that accept a servlet
dispatch call in and respond out. Nothing else in our design implements any
servlet APIs that can accept a request/response in a different way.
So it's difficult to understand how we could possibly be passed in a different
instance than the original one the servlet dispatch received since there's
nowhere for it to occur.
That's why we've struggled to grasp what the risk is as this has come up at
times.
I fully appreciate that you're speaking from a container/generality perspective
here and that in the general case what you're saying is obviously true. And
yes, it's an anti-pattern because it makes assumptions that aren't generally
true. I'm strongly suspecting they are, however, still true for us (and frankly
for the vast majority of traditional apps that just implement Servlet).
Basically it feels like for this to break, something has to call an API that
also involves passing in a callback interface that itself has to receive the
request/response back.
-- Scott
_______________________________________________
jetty-users mailing list
[email protected]
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jetty-users
