Hi,
This seems like the crux of the issue. MP and the Jakarta Core Profile don't require Servlet, and there are implementations that don't see Servlet as something useful for them. We also have important implementers of Servlet who don't see EE Full Platform or Web Profile as useful for them. But EE has security specs that are tied to servlet.
Well, the question is, are they really tied to Servlet conceptually, or is it more of a belief?
The two SPIs which Jakarta Security uses for integration with a container (Jakarta Authentication and Jakarta Authorization), are those really tied to Servlet? Or do people just assume they are?
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.
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. :)
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.
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev