Hi, Thanks for the update. Not sure why TomEE included that or if TomEE 9 would target Jakarta EE 10 because in 9 that is not part of the Standard yet, but the members of the community who already presented their dependency Analysis to the platform Team a few weeks ago (I assume Arjan you were there if you had time) mentioned in their JavaLand presentation (I don’t think Rudy was in that session but he was at JavaLand in several other Jakarta EE related talks) „Meet the Libs“ that even some specs referenced pre-release versions of other specs and Technologies therefore Maybe TomEE also did that before Jakarta EE 10 went live? The Broad discussion Rudy mentioned happens at the latest in the Spec Committee when representatives of vendors and the community review the specs and may ask for changes or even vote against it if they feel it is not ready. I only have one voice and if others like Tomitribe already started exposing a premature version of the new API in their products, maybe they have another opinion, but I would be more comfortable if the redundant Name Attribute was removed if that Name is Nothing but a copy of getCallerPrincipal().getName(). Kind Regards, Werner Sent from Mail for Windows What's the value of getCallerName over getCallerPrincipal and have something proprietaty if the standard offers a unified way that supports multiple Authentication mechanisms, not just OpenID Connect?
Indeed, if the reason was to have the very specific OpenID "raw" response available for some reason, then I might make some sense. But a developer only wanting to work with 1 object is maybe not a very good reason. There are many other objects in a typical Jakarta EE application a developer works with. There seems more value in the getCallerGroups method as at least SecurityContext one of has to query a little more complex,
We actually had a getCallerGroups in the SecurityContext, but Alex argued to remove it at the last second; citing concerns over unlimited lists of groups being returned. This was one of the things I had hoped to address for 3.0, but alas. We can put that on the agenda for the next version. but e.g. Spring Security does not duplicate things either.
Spring relies a lot on inheritence so the OicdUser is just a subclass of its Principal element but there is no redundant method name there either. The whole groups Design also looks different via just claims, so the getCallerGroups can be seen as a convenience method. I highly recommend avoiding redundancies. You can always add things later but it's very hard to remove something from a standard. Not offering it in 10, well it's been in Spring for over 3 years now, so how long should we wait? Plus wasn't it in 9 already or did TomEe put something premature into 9?
Interesting, I think TomEE did something wrong there. This particular version I started with Gaurav in August 2018, so close to 4 years ago. I'd love to have an even wider group of people validate it, but realistically I think that's just not going to happen. Arjan Tijms |
