> Problems start to occur when a request/response is wrapped in > another object that abstracts away from the request response paradigm > and just looks like some dataful object (which just happens to be backed > by data a request). Such objects can easily be put into persistent data > structures that have no lifecycle relationship to the original request.
Yes. We actually changed a lot of properties on singletons from taking an HttpServletRequest to Supplier<HttpServletRequest> precisely because while *we* know we're not injecting an actual request object but rather a proxy for one, it's not obvious from the code. That was not good. But they were never being given an actual request. Only a proxy for retrieving the "current" one. The hitch is how one can know what the current one is across a call stack and that's where we used thread-locals. But we have never had any lifecycle problems, because we populate the thread-locals from a filter and the filter clears them during the unwind, and it's never caused any trouble. What we're concerned about is the drumbeat that a non-async-using servlet request that's just executing methods on objects via the stack could start out on one thread and switch threads in the middle. And I just don't see how that's remotely possible or sane. And if it is, the spec went to a very bad place and a lot of software is screwed, not just ours. -- Scott _______________________________________________ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
