I see that the Github organization https://github.com/javaee-security-spec still has references to the java.net infrastructure (mailing list and spec page). I don't know who has the proper rights to u

The version can be pushed again to Bintray again if needed based on the tag. Let me know if this needed.

All, The delete button says that I can't delete the package, nor released versions if they are older than 6 months. So I deleted as many versions as possible. Only m01 could not be removed. But that s

All, Bintray packages can be deleted. Don't know what happen if they are mirrored on JCenter. Since I see the API and Soteria artifacts on Maven Central, I'll delete the packages from BinTray. Best re

Hi All, I have updated the Soteria version to 1.0-m06-SNAPSHOT. I also used the 1.0-b06 version of the API, and thus updated the imports to reflect the new package structure within API. The work can b

Arjan, Ok, if Soteria is still writable, I'll have a look at the outstanding PR's and try to make it compilable again against the current spec-api. I had the impression from the communication by Will

Does this mean we no longer can help by writing code? At this moment the repo for Soteria contains code which no longer compiles, so that means that I need to improvise for my presentation which I nee

I find the "SecurityContext.getPrincipalByType(Class <? extends Principal> pType)" A good idea. Some other frameworks (like Apache Shiro) use the same concept. - User/Caller is identified by a Collect

Thx Guillermo, missed that one. Things are compiling now. I can update now some tests which are not up to date yet. Best regards Rudy

Hi All, I was trying to update some examples I have for a presentation with Soteria. But the current code in Github https://github.com/javaee-security-spec/soteria gives me issues. It points to 1.0-m0

Arjan, With my remark, We don't do the *complete* security. I was referring to the fact that we only do it for Java EE, not SE for example. So we don't do the *complete* security for the JVM was a bet

Hi, A sub package of javax.security is maybe a better idea. We don't do the *complete* security. I agree that we need to avoid abbreviations as they are not as clear as the full name. Best regards Rud

Hi Daniel, The reason these XML files are there is to be able to run Soteria on the Java EE 7 servers. They will not be needed on Java EE 8. They activate JASPIC which is needed for Soteria. Hope this