[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [servlet-dev] Big ticket items for Servlet 6 / Jakarta EE 10?
|
Hi,
On Wednesday, September 2, 2020, Stuart Douglas <
sdouglas@xxxxxxxxxx> wrote:
Wouldn't it make more sense to just allow traditional Servlet's to be CDI beans? We do this in Quarkus, which means that scopes, interceptors etc work as you would expect. In Quarkus you can just add @Transactional to a Servlet and it will just work.
As explained elsewhere, that’s of course an option as well, though from experience the pure bean approach would be clearer. Don’t forget the big service method on Servlet that allows to override individual doGet etc methods, thereby circumventing interceptors on those.
Of course it can be done (as you proved), but there’s extra rules and behaviour users should be aware of. Ultimately it’s a choice: reusing an existing type with some caveats (and this has maintenance and complexity costs) or introducing a new type and having the cost of having a second type around.
Another, perhaps even more important reason for this is to have a place to put the CDI based producers (Bean<T>s really), which are now in CDI core, to inject instances like the current HttpServletRequest. Those are in need of some overhaul (e.g, it's not at all defined which *current* HTTPServletRequest is injected, think original, vs wrapped, vs one after an include or forward etc). The CDI spec has indicated those things never belonged in CDI. CDI is to be used as a foundation for other specs, not as a Facade for Servlet and others.
IMHO the Servlet API should not contain these producers, they should be left to the vendor to implement.
I’m not 100% what that means. Don’t vendors always implement these, by definition?
What it concerns here is that the spec for them is maintained by the Servlet spec, and behaviour is evolved via the Servlet spec. Compare this to JTA. The CDI extensions for it are maintained by the JTA spec. CDI doesn’t contain the extensions needed for JTA.
If we want to define this behaviour IMHO it makes sense to include a section in the specification talking about the CDI integration and defining what Servlet based CDI beans are required if both technologies are in use.
Indeed, that’s the idea. Note that the CDI spec lead asked for this before in an effort to clean up CDI somewhat; making CDI the pure DI / Component model that doesn’t say much if anything about specs like Servlet, Faces, etc.
Kind regards,
Arjan
