How about some of the streamlining and better synergies between EE Security and JAX-RS, especially the redundant and in its current form incompatible SecurityContext both got?
There are essentially compatible, in that when you authenticate officially in Java EE, they both return the same principal and the same role checks would return true on both.
I'd say the first step is to have either @RolesAllowed specified for JAX-RS, or, have a new CDI interceptor based annotation (in EE security) that would work for JAX-RS in the same way as one expects @RolesAllowed to work today in JAX-RS.
The JAX-RS SecurityContext can essentially be deprecated, just as the @Context annotation can. There's no need for JAX-RS to focus on things that can already be done by other specs/APIs (no need to reinvent or duplicate wheels).
Kind regards,
Arjan
Hi,
but instead shall only wrap existing features under a common hood. What I did is adding feature to API AND to Jersey parallel, and encouraged other vendors to follow.
Yeah, lol, that's of course not how it will likely work or be interpreted in practice.
Of course we can propose and work on new features. We can "quickly" (Just In Time) implement these in Jersey, to make it count as an "existing feature", but that's just another interpretation of the Code First approach that's promoted by Eclipse. It's not that crazy different from how we did things in JSF and EE Security before. Basically everything added to the spec and API was first implemented in Mojarra and Soteria.
Kind regards,
Arjan
Well, from my point of view, the API should add features and force implementors to keep up. If we only ask for a feature from RestEasy, then the whole point of JAX-RS is gone... but I guess that's a neverending discussion.
Mihai
In fact JAX-RS is just an API, not a product. So unless some implementations (like Jersey, CXF, RestEasy, etc.) already support your wanted feature, it might be a good idea to contribute your wanted feature to one of that products first. This makes it much easier for the vendors to agree to your feature proposal in the API as they do not have to invest their own ressources or at least have a guiding blue print (RI) then.
-Markus
Hi Mihai,
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community