Re: Independent JSR 375 implementation


Guillermo González de Agüero
 

While I see the point of the independent library, I still advocate for a good RI that goes beyond the spec. A 3rd party library reaches more people, but what's the benefit of having 5 different implementations that don't go beyond the spec, and then a library that provides extra funcionality for every implementation?

IBM and more than probably RedHat will go with their independent implementations, and they will try to make them better than the others. Why should we do the same? The RI is just another implementation. Weld or Jersey are good examples of RIs that experiment and provide extra features. I think we could do the same with Soteria.


Regards,

Guillermo González de Agüero

El mié., 29 nov. 2017 a las 17:39, Arjan Tijms (<arjan.tijms@...>) escribió:
Hi,

First of all thanks for the reply, good to see you here again ;)

There's some things that are best changed in the API, specifically the CDI 2.0 inspired annotation instances/builders. If I'm not mistaken, CDI 1.2 and JSF 2.1 (two MRs done outside Java EE) could not been officially included into Java EE 7 resp EE 6 either, but many vendors choose to include these versions anyway.

Private modifications to the RI are probably not so nice in this case, as it concerns things that should be available everywhere, so also on Liberty.

There's an amount of RI implementation things to be done though, basically just small bugs. There's a bug where the URL attribute of the ldap store was accidentally left constant, and I think there's a NPE somewhere if the password is left blank in the BASIC mechanism. My guess would be that those things would be relatively easy to do; release a Soteria 1.0.1 with just bug fixes.

Unless a MR can still be done, maybe the best way forward is to incubate the mentioned changes in an OmniFaces like library, perhaps OmniJSR375 or so.

Kind regards,
Arjan Tijms

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