With regard to CDI scopes and servlets, I think it would be a really REALLY bad idea to try and support scopes for servlets and filters.
A request scoped servlet would essentially be much the same as a javax.servlet.SingleThreadModel servlet - which was a bad idea then and is still a bad idea now. It added needless complexity to the container whose cost was/is paid by all users regardless when most do not use SingleThreadModel.
I fear that trying to get similar support for CDI built into the core container will have similar no-taxation-without-representation issues.
It should not add any complexity, other than delegating to CDI to create the Servlet. If the Underlying object is RequestScoped then the Servlet container does not have to do any additional work, it just forwards requests to the proxy it has been handed and the CDI container takes care of the details
I think we are on the same page then. I was fearful that the suggestion was that for scoped requests, the servlet container would need to run the full Servlet lifecycle of init & destroy via CDI, which would add extra complexity to the container. But if it is just that CDI gives the container a single servlet instance that is initialized/used normally for the full context lifecycle and that it delegates internally to dynamically created instances - then that is fine.
So does CDI need any other facilities from the servlet container, other than to plug into the initial component creation and/or decoration?
It just needs creation. You can come very close with decoration, but there are some things (e.g. constructor injection) that require control of creation.
The other things it needs such as activation and deactivation of the request scope can already be handled by the existing listeners we provide.
That said, there is no way we will be recommending different scopes for Servlets, the real value here in addition to injection is that you get interceptor support, so you can just add @Transactional to your servlet and it will work as you expect. Scope support is basically a by-product of this, and not something that is particularly interesting IMHO.
Can interceptor support be added by a CDI provided proxy servlet?
It just comes automatically. If you have an instance provided by CDI interceptors will 'just work'. Basically the container is invoking on a CDI bean, and from CDI's POV it is the same as any other user invocation, every feature should work as normal.
Where there is some ambiguity is around self invocation and interceptors. If you are using proxies to implement interceptors then once you are 'inside' the proxy then invocations on other methods of the same instance with interceptor bindings won't be intercepted. e.g.:
class Tmp {
void a() {
b();
}
@Transactional
void b() {
}
}
If you call b() directly from a container or other code it will alway be intercepted, but if you call a() first that then calls b() from the same instance it is not clear that this code path also has to be intercepted (unless this has been cleared up in recent versions of the CDI spec).
This affects servlet because if you have an impl where b() won't be intercepted adding an interceptor annotation to one of the methods of HttpServlet won't work.
From a Servlet PoV I don't think this matters, because it is easy to work around within the creation API that we provide, if self interception is not supported you just return another non-CDI proxy, that directly delegates to the appropriate method so interceptors will be applied.
The Servlet container does not need to do anything, just call the service method on the Servlet the CDI container has provided. Basically as long as you have a way to delegate creation of the Servlet to CDI then this is all that is needed from the containers point of view, support for scopes and interceptors is wired into the object that the CDI container creates, and is totally opaque to the Servlet container.
Great, so we just need a factory interface that will allow the implementation of `ServletContext.createXxx` to be pluggable. It would be good to also clean up the destroy as well and to make that equally pluggable.
Well IMHO it's more important to allow creation of 'normal' discovered Servlets to be pluggable. ServletContext.createXxx does not really matter because you can just use CDI.current().instance(Foo.class) instead, if you really want to create a CDI ready instance. I don't see the createXx methods as being particulally important, I think the main idea is that you can bundle CDI into a Servlet container and it can take control of the Servlet/Filter/Lister creation process.
Stuart
_______________________________________________
servlet-dev mailing list
servlet-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/servlet-dev
