Maybe a bit of both? People probably wrongly assume there's a strict tie, but OTOH the common use of Jakarta Authentication is via the Servlet Container Profile. So I think it's reasonable for vendors thinking about bringing Jakarta Authentication into their architecture to expect that the real-world usage hardening of any spec impl is going to be related to servlet workloads.
I hear you, but that's also indeed the common misconception. Obviously the one remaining real world usage of Jakarta Authentication is via the Servlet Container Profile, but even that one only describes behaviour for a Servlet container. There's no actual Servlet (or any other) dependency. See the pom at
https://github.com/jakartaee/authentication/blob/master/api/pom.xml
Furthermore, and maybe even more importantly, what stops us from creating a REST Container Profile? Jakarta Authentication could relatively easily add a chapter/profile for behaviour in a REST environment.
Jakarta Security itself has the HttpAuthenticationMechanism, which uses the HttpServletRequest and HttpServletResponse. As I've argued before, it's a truly sad state of affairs that in Jakarta EE (and Microprofile) we've come to have important vendors who don't see the most basic of basic things of the web (the request and the response of an HTTP request) as useful for them.
WildFly, of course, provides servlet in all our standard configurations, and I'm not going to comment on the reasoning behind server implementations that don't. (I am interested in the thoughts of the WildFly developer community regarding this though; see [1].)
I will say though that Jakarta Servlet is more than an API jar for defining an object that represents a request and a response. :)
It is, so is this where we all went wrong? Has Servlet become too much? And if so, which parts are too much?
I really find it rather concerning that Jakarta EE as a server side platform has run into a situation where we don't have a common representation for a few basic things such as the HTTP request and the response. REST and Servlet are in some bizarre competition there, which should, IMHO, never have been the case.
Part of what drove my first response is the discussion last week on the monthly EE platform architecture call related to the proposed CDI Centric approach[2] to the EE platform and how that might relate to Servlet vendors who aren't focused on the EE platform or web profile. Seems wise to me to get more clarity on how that will play out before moving or duplicating MP JWT.
True. Part of that depends on how we position Servlet; as a high level technology, or as a fundamental (core) technology. Currently the architecture there is rather messed up to qualify as low level:
- Servlets are managed beans according to the (now pruned) Managed Beans spec (supporting @Inject etc), alluding to being high level components
- Servlets support user friendly annotations like @WebServlet and @ServletSecurity, alluding too to being high level components
- REST is in the core profile, Servlet is not. This somewhat suggests Servlet is high level, and REST is low level (reality is of course the other way around)
Kind regards,
Arjan Tijms
