Re: Java EE Security.Next

reza_rahman <reza_rahman@...>

Obviously an MR is the best route if Oracle has the appetite. If not I suggest an RI specific extension. The last resort could be a fork.

Sent from my iPhone

On Nov 26, 2017, at 12:33 PM, Arjan Tijms <arjan.tijms@...> wrote:


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:
* 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;

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?


Kind regards,
Arjan Tijms

Join to automatically receive all group messages.