-1 Aside from Scott’s concerns (which I’d love to hear more what exactly „REST light“ should be other than e.g. separating Server and Client part) I am missing Integration with Jakarta Security and replacing the redundant isUserinRole() with the identical isCallerInRole() from Security. Especially for a release touted as „This will be the first backward incompatible release of Jakarta REST.“ I see it as crucial to finally do that in 4.0 and not seeing it among the planned Features is disappoining. Werner The core profile is quite an important thing we want to bring in Java 10, and if we need a JAXRS-lite, it should probably be mentioned. But as far as I understand, it's still not clear what we'll need and how so mentioning now is probably premature On the other hand, not mentioning it in the plan review does not mean we can't work on it, right? For security I'd like to see more than what's in the plan review. Of course it's totally fine to vote -1. But for my own understanding and knowledge, can you please clarify what you mean with > there needs to be some post 3.1 release of the spec that addresses integration with the core profile What are your expectations? Can also be done outside of this email thread or during a spec call. Again, just for my own curiosity. -1 Red Hat. As I commented on the issue, there needs to be some post 3.1 release of the spec that addresses integration with the core profile. On Thu, May 27, 2021 at 4:16 AM Andrew Pielage <andrew.pielage@xxxxxxxxxxx> wrote: Andrew Pielage Java Developer at Payara Services Ltd Payara - Supported Enterprise Software for Jakarta EE and MicroProfile Applications 
Greetings Jakarta EE Specification Committee.
I need your vote to approve the Plan Review of Jakarta RESTful Web Services 4.0.
The JESP/EFSP states a Plan Review provides a means for the Specification Project Team to present their Release Plan to the Project Leadership Chain, the Specification Committee, and the community for feedback. Also, the JESP/EFSP requires a successful ballot of the Specification Committee in order to ratify the Plan Review.
The relevant materials are available here:
https://github.com/jakartaee/specifications/pull/351
https://deploy-preview-351--jakartaee-specifications.netlify.app/specifications/restful-ws/4.0/
Per the process, this will be a seven-day ballot, ending on Tuesday, June 1, that requires a Super-majority positive vote of the Specification Committee members (note that there is no veto). Community input is welcome, but only votes cast by Specification Committee Representatives will be counted.
The Specification Committee is composed of representatives of the Jakarta EE Working Group Member Companies (Fujitsu, IBM, Oracle, Payara, Red Hat, Tomitribe, and Primeton), along with individuals who represent the EE4J PMC, Participant Members, and Committer Members.
Specification Committee representatives, your vote is hereby requested. Please respond with +1 (positive), 0 (abstain), or -1 (reject). Any feedback that you can provide to support your vote will be appreciated. -- Ivar Grimstad Jakarta EE Developer Advocate | Eclipse Foundation Eclipse Foundation - Community. Code. Collaboration.
_______________________________________________
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec
_______________________________________________
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec |
