Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] Moving MicroProfile JWT to Jakarta Security?

In the short term, moving Microprofile JWT to Jakarta as a _separate_ spec seems logical to me. That way the only real change for MP users is the namespace, and Jakarta Security can easily consume it.

I think Arjun is on to something with respect to rethinking Servlet, though. Do we need to split it up into parts that are more easily consumable by MP implementations that currently don't want to use it? I agree the whole fear of using it (whether justified or not) is quite confusing from a developer's perspective. Also, do virtual threads suddenly make Servlet more appealing, or is there more than the thread-per-request nature of it that vendors shied away from?
___

Kito D. Mann | @kito99 | Java Champion | Google Developer Expert | LinkedIn
Expert training and consulting: Cloud architecture, Java/Jakarta EE, Web Components, Angular
Virtua, Inc. | virtua.tech 

* Enterprise development, front and back. Listen to Stackd Podcast.
* Speak at conferences? Check out SpeakerTrax.


On Sun, Nov 6, 2022 at 3:32 PM arjan tijms <arjan.tijms@xxxxxxxxx> wrote:
Hi,

On Sun, Nov 6, 2022 at 6:19 PM Brian Stansberry <brian.stansberry@xxxxxxxxxx> wrote:
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




 
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

Back to the top