Java EE Security.Next


Arjan Tijms
 

Hi,

Without an EG being active and with the EE transfer in progress so that there's being little chance of starting an EG now or before long, I wonder what the best way forward is at this moment for JSR 375.

Working with the spec I noticed a couple of (small) inconveniences myself:

* We forgot to include annotation literal instances/builders such as done by CDI 2.0: http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#built_in_annotation_literals
* We forgot to spec and make the SecurityContext bean @Named, making it more difficult to use on JSF views than it should be
* Java EE Security 1.0 being Java EE 7 dependent doesn't take advantage of the CDI interception factory, making it more difficult than it should be to apply @RememberMe to the build-in mechanisms; http://arjan-tijms.omnifaces.org/2017/08/dynamically-adding-interceptor-to-build.html

I'd like to work towards a small release (a MR?) to address these and perhaps a small number of other issues that came up after release and/or were already identified before.

A number of options to consider:

* Do an MR release - these are typically low overhead and can be done without too much process, but will Oracle sponsor that at this time?
* Wait for everything to be transferred to EE4J - could take a year or more
* Incubate something within MicroProfile - can we actually incubate a next version there, or only do add-on stuff? I think the latter
* Create a branch in Soteria and API, incubate proposed features there like Weld did for Weld 3 - Problem, Will still has the JSR 375 API project closed
* Create an open source fork of Soteria, incubate proposed features there - may be quite confusing to users
* Create an open source add-on project (like OmniFaces for JSF) - already discussed this with Rudy before, but can not change API classes
* Something else?

Thoughts?

Kind regards,
Arjan Tijms

Join javaee-security-spec@javaee.groups.io to automatically receive all group messages.