The "servlet" here is 100% a bean, meaning all usual CDI features work out of the box (interception, decoration, alternatives, vetoing, scopes, etc).
What does @Requestlet do here that @WebServlet does not? Why not just allow @WebServlet on an annotated class, and just add the method annotations (nothing to do with CDI)?
That's a good question. The answer is to distinguish these "servlet beans" from plain servlets. Re-using @WebServlet, and looking for all classes with this annotation, would result in a collection of both traditional servlets and these beans.
TBH I think the value of annotations here is somewhat limited, as the method signature always has to be the same (as opposed to something like JAX-RS, where the methods can have any signature), but I think it makes sense to have it for completeness.
Well, a bean can have multiple methods of course, and each method can handle a different HTTP method that way.
Why not just allow Servlet's to be full CDI beans? We do this in Quarkus, and I don't think there would be any backwards compatibility concerns.
Another good question. One that we discussed to death in the JASPIC EG back then; do we upgrade SAMs to be full CDI beans, or do we layer a bean type on top of it?
Ultimately we found the latter to be much cleaner in terms of design and expectations by developers. Servlets could then be either plain servlets, or those in-between things we have today where they support some injection features (according to the Java EE Managed Beans sub-spec), and then also full CDI beans.
To support this in Servlet containers such as Tomcat and Jetty would need some instance management API of some kind. With that I mean an API where Servlet containers never instantiate or store Servlets themselves, but always request these from some API. The implementation of this API can then delegate to say Weld, or to the existing code Servlet containers are using. I suppose it can be done, but might be more invasive to Servlet itself.
Note that this is exactly what we did in Jakarta Faces (JSF); existing non-bean Converters and Validators can be treated as full CDI beans since 2.3. In retrospective, I think we'd been better off just defining a new type for this, as now it's just clunky and has small behaviour differences that confuse people.
Kind regards,
Arjan Tijms
