1. javaee-security-spec@javaee.groups.io

Re: Java EE Security.Next

Rudy De Busscher
 

If possible, an MR is the best option.

But we can already start experimenting with additional + proposed features outside JCP and EE4J (I don't think Microprofile is a good place for it), and even play with some new API.

That way, we are prepared and can go faster/further at the moment we can start with our work within the Eclipse Fdn.

I already created some add-ons for handling Tokens (JWT and (Google) OAuth2). See (1) and (2)

regards
Rudy


On 26 November 2017 at 19:57, Guillermo González de Agüero <z06.guillermo@...> wrote:
Just thinking out loud... Perhaps Will could open for us an API branch and non official snapshots of development work could be used by servers?

Work would be done when the time for an MR arrives (or the donation is finished).


Regards,

Guillermo González de Agüero

El dom., 26 nov. 2017 18:33, Arjan Tijms <arjan.tijms@...> escribió:
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.