CDI needs more than just the instance to destroy the object properly, and you really need to let CDI actually create the instance to get interceptors etc.
Ideally you want an API that looks like the Undertow one:
public interface InstanceFactory<T> {
InstanceHandle<T> createInstance();
}
public interface InstanceHandle<T> {
T getInstance();
void release();
}
The problem here is that we already have the factory methods `ServletContext.createServlet(Class) etc.
You can't really destroy these properly, unless you have an IdentityHashMap that tracks the instances (EAP6 actually did this, it's not as bad as it sounds because Servlets are usually only created once).
The servlet, filters and listeners returned are intended to be added with the corresponding add method, but they could be wrapped or used in some other way. Thus we don't have a good way to pass around the InstanceHandle.
Filters and Servlets have destroy methods, so perhaps there is some scope to somehow wire them up to some CDI release mechanism, but Listeners don't have the same.
We could just say that in this case the objects will not be destroyed according to the contract. I don't know how common this is, and also if you really care you can just use CDI directly to instantiate the Servlet's instead of the Servlet API. We could still use this internally to create/destroy the container managed objects, which covers the 99% use case.
Stuart
So I'm totally on board with making these create methods able to delegate to CDI (or some other factory method), so having a pluggable factory is a good start. But we need to consider how we trigger release in all cases - including when the instances are not directly passed to an add method.
Thus I think we need to clean up these lifecycle methods to make sure they cover the full livecycle of the object. Once we do that, it should be trivial to make it pluggable and thus be able to plug in CDI
cheers
--
servlet-dev mailing list
servlet-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/servlet-dev
