Hi,
This is more or less how it is done today anyway, just without a standard API. We have a Decorator API with the methods:
void destroy(Object o);
For scopes to really work you'd actually need to call this every time you need to use a Servlet,
Well that is another use-case not just related to CDI. A standard way of scoping calls/threads to Filters, Servlets, Listeners would be useful for metrics and other things. But isn't that a different mechanism than the creational decoration/destruction?
We also need to consider async, where we can already anoint a Thread/Runnable to be running on behalf of a context. Perhaps we also need to allow explicit async scoping to be more fine grained (ie Filter, Servlet and/or URI)?
although I guess you could use this to return a proxy first, which then delegates to the actual scoped Servlet that is fully managed by CDI (which would essentially boil down to the bridge servlet I presented above).
I'm not seeing anything in your bridge servlet above that needs to be in the Servlet API. You can already do as much with a framework that creates its beans in a SCI and adds the bridge servlet. What is it that prevents that technique being used today?
I'm very much in favour of changing servlets so that frameworks can do cool and funky stuff easily. I've very much against picking specific frameworks that we will support in servlets. So are there any features missing to make implementing your bridge servlet model easier (or possible if I'm missing something and it isn't possible now).
Regardless, the existing structure of a Servlet with its service method and overrides is IMHO not a very good fit for a bean model and interceptors.
Indeed there are oh so many things not right with Servlets. But it is what it is! Alternative models are fine, but I think they should be developed elsewhere. Here we should restrict ourselves to what is the best we can do to modernize the API, but for it still to be fundamentally a Servlet API.
cheers
