That is good to know, thanks. Will try it probably on Monday when I get to that demo for security I have to do. Werner

If the hints for build-time by Arjan work (deployment in Payara 4 build 174 or above should be fine) I guess that'll do for the client I'm helping with security and identity management right now. For

Will try those in the POM of the dev environment tomorrow. Would be great if it works to show them Soteria in the security PoC, but nevertheless it would be as great if Oracle or someone else could re

I know but the client currently only uses Payara 174 at most, and the WAR still must be built against a valid Maven repo, no snapshots allowed there. If Payara has public (Final) Maven JARs I could us

All, I just found a very bad bug in Soteria 1.0 as it's out there in MavenCentral since August 2017 ;-/ I can't even set labels like "bug" but it is clearly a major bug and showstopper from using Sote

I should also be on the list of initial committers at least I told Dmitry who asked for Oracle that I would like to join JSON-P, Security and JMS-related projects. Kind Regards, Werner

Hi, I am currently helping a large client who needs Role and Identity Management in a Microservice environment using Java EE (Payara to be more precise, which helps because it got Soteria built-in rec

Will/all, I'm not sure, what Oracle plans for Java EE 8, but JTA just launched a MR 6 and that's clearly not yet targeting EE4J either: https://jcp.org/aboutJava/communityprocess/maintenance/jsr907/in

I hope everyone is clear, that javax.json-api is the API/Spec, not implementation of JSR 374? I asked Dmitry, if they were intended to be merged into the EE4J project or a fix/Patch, etc. of Java EE 8

Hi, I spoke with David Delabassee yesterday after his Java EE talk at JVM-Con. He sounded quite reluctant of a MR. So better wait for EE4J. However, if you look at JSON-P, at least 2 "patch" releases

Yes, nobody should bother creating another Java EE Security API organization on GitHub again ;-) Some JSRs have already been contributed, a few others are pending, but already mentioned. Mostly those

Now that several existing JSRs like 374 started with proposals to EE4J, I wonder what keeps this JSR from doing the same? Obvious bugs or smaller improvements without introducing whole new API element

Dear All, The JCP page has not been updated yet, but JSR 375 won the JCP Award for Most Significant JSR as announced at the JCP Party last night: https://jcp.org/en/press/news/awards/2017award_nominee

This overlaps with JavaOne, but maybe someone in Europe or the UK who can't make it to JavaOne this year could also enjoy this Security event. Kind Regards, Werner ---------- Forwarded message -------

All, At the moment Rudy's poll has "EE Security" before "JSA" and "JSEC". Can we please ensure, that the final acronym remains valid even after Java EE was turned Open Source? With all the various acr

All, Thanks Rudy for the update on the poll. As long as the term "EE" will not be disallowed in the very near future, I find it OK. Otherwise if "Java EE" or abbreviations must not be used by the upco

Will, Thanks for letting us know. After the examples are in the main Java EE organization, I trust they can also be adjusted to match the final state of the JSR ;-) So those of us who present Java Sec

Wherever that might be, but especially in this JSR the spirit and constructive contribution by community members already showed how it could work even more smoothly in some Open Source ecosystem for J

pfd2, what was the purpose of that? I guess with release tags for all major milestones like PFD or FAB, this branch does not need to be preserved either. Werner

It could be in the issue tracker, a Wiki (if the project uses that) or just parts of the project site, as long as the ideas are there to discuss and maybe act further. A lot of the code was merely lik