> Don't just reference the one year old release to comment they are old. MP is working on MP 6.0 and all of the MP specs should work with either Jakarta EE 10 and EE 9.1. We will be able to >work out a way if Jakarta EE spec is willing to use MP specs. That doesn’t solve the problem that in the current dependency cycles MP will ALWAYS lag behind, whether 6.0 gets out 3, 6 or 9 months after Jakarta EE 10 itself had been finalized, the consuming API would have to rely on a not yet available 7.0-SNAPSHOT. So Security which already faced some challenges with OIDC and other Features could be even further delayed and had to postpone features like JWT having to wait for the next MP version to align and be ready, so JWT support could only come in Jakarta EE 11.1 instead of 11 just as one example. >It looks like you missed the MP GraphQL 2.0 release, which aligns with Jakarta EE 9.1. It looks like that missed the MP 5.0 „train“ which means, unless a consolidation happens in 6.0 or above such acyclic APIs make Things even worse because they may yet again depend on different versions of the Jakarta EE stack. >Isn't that an opportunity where Jakarta Security could reference MP JWT? >i.e. the MP JWT specification doesn't specify how it is implemented, but the Jakarta Security specification could reference the MP JWT APIs and configuration and define how these are >implemented in Jakarta Security? It would lead to cyclic dependencies, for Jakarta Security alone both CDI and JSON Processing, and assuming multiple Jakarta EE APIs wanted to consume MP APIs, that potentially gets worse. https://microprofile.io/2021/12/07/microprofile-5-0-release/ lags behind Jakarta EE 10 until at least 10, so a Security API Catering towards Jakarta EE 11 already had to use a MP JWT API based on much older APIs like CDI 3 etc.
Don't just reference the one year old release to comment they are old. MP is working on MP 6.0 and all of the MP specs should work with either Jakarta EE 10 and EE 9.1. We will be able to work out a way if Jakarta EE spec is willing to use MP specs. Then there are even some „outside the umbrella“ like MP GraphQL 1.1 that were not even upgraded and are still on the API Level of MP 4.1, hence if they consume any Jakarta EE APIs then it gets even worse using those as well.
Werner For specification projects in a related space, the existence of more than one needs to be justified. There is a reason everyone involved in specification/standards work raises this well trodden satire out at some point:
So what do you propose instead then? Having a Jakarta Full-profile or so that includes both EE and MP? As a Jakarta EE user, we can now freely use Form, Basic, Open ID Connect, but not JWT. Even when a MP profile JWT implementation is added, it's not necessarily based on Jakarta Security. Even in a Jakarta EE server that already includes MP components, its JWT implementation does not necessarily have to be Jakarta Security based. Meaning, things like additional identity stores, interceptors, etc are not being picked up for JWT or may even clash.
Isn't that an opportunity where Jakarta Security could reference MP JWT? i.e. the MP JWT specification doesn't specify how it is implemented, but the Jakarta Security specification could reference the MP JWT APIs and configuration and define how these are implemented in Jakarta Security? _______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev _______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
--
Thanks
Emily |
