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?
A scope in CDI is a very specific thing. It essentially means that the CDI runtime is in charge of creating and retrieving an instance in a given context. But it's probably best to read up a little about what a scope in CDI exactly is (utterly shameless plug: I can highly recommend this book
https://amazon.com/Pro-CDI-Java-Depth-Dependency-ebook/dp/B07XGQCSZ2 :P)
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?
Nothing basically, except that the bridge servlet would have to be defined and then supplied by something. Hence why I proposed a sub-spec (or, related, standalone spec), like e.g. Jakarta Server Pages (JSP) is today.
I've very much against picking specific frameworks that we will support in servlets.
The problem is of course that Servlet is not so much an external random API, but is part of Jakarta EE. CDI here is also not just any random framework, but is the bean model and injection facility in Jakarta EE.
Kind regards,
Arjan Tijms
