Topics

Independent JSR 375 implementation


Arjan Tijms
 

Hi,

For the ones who haven’t seen it yet; OpenLiberty started with their own implementation of JSR 375.

See: https://github.com/OpenLiberty/open-liberty/tree/master/dev/com.ibm.ws.security.javaeesec/src/com/ibm/ws/security/javaeesec


Will Hopkins
 

Hi All,

I'm discussing this internally to figure out what the best way forward is. Conceptually, of course, an MR is what we want, but as Bill pointed out to me, an MR couldn't be included in Java EE 8 under the current rules, so making it widely available probably requires making it available under EE4J somehow.

There is reluctance to make changes, even on a branch, in the GitHub repos, as that may impede the migration to Eclipse.

Similarly, if the code were forked -- at least, if it were forked with the intent to eventually submit the changes back to EE4J -- then the forked code would need to be managed carefully to ensure that IP rights properly protected and that the resulting code was "IP clean" to submit to EE4J.

The idea of making some private modifications to the RI to address the short term needs is in some ways most appealing -- it's certainly the most expedient and logistically simple, I think -- but I think there would still be a need to carefully track IP, since the goal would (presumably) be to submit back to an eventual Java EE Security.Next.

Thoughts?

Will

On 11/27/2017 04:28 AM, Arjan Tijms wrote:
Hi,

For the ones who haven’t seen it yet; OpenLiberty started with their own implementation of JSR 375.

See: https://github.com/OpenLiberty/open-liberty/tree/master/dev/com.ibm.ws.security.javaeesec/src/com/ibm/ws/security/javaeesec


-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Developer Experience
35 Network Drive, Burlington, MA 01803


Arjan Tijms
 

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


Werner Keil
 

Hi,

I spoke with David Delabassee yesterday after his Java EE talk at JVM-Con. He sounded quite reluctant of a MR. So better wait for EE4J.

However, if you look at JSON-P, at least 2 "patch" releases were published officially to MavenCentral without a MR:
https://search.maven.org/#artifactdetails%7Cjavax.json%7Cjavax.json-api%7C1.1.2%7Cbundle

So this seems possible. For slightly different reasons (there the Maintenance Lead is completely inactive and unavailable for 2 years, more like what EE 8 had in 2016;-/) we also did a patch release at JSR 354. However both patch releases only contain tiny things, sometimes just a typo in the JavaDoc or a JUnit test not properly annotated, etc. This is not something for any structural change. If it is also adding or changing an annotation or fixing an accidential "magic number" I would suggest exploring the way JSR 374 did it already.

Werner


Bill Shannon
 

I hope everyone is clear on the difference between spec and implementation.  Spec changes require use of the JCP, implementation changes do not.

If there are bugs in the Soteria implementation of JSR 375, those can be fixed without using the JCP.  We just need to coordinate those changes with the contribution to the Eclipse Foundation and with a potential GlassFish bug fix release.

Any changes/fixes/enhancements to the APIs needs to wait until the EE4J spec process is defined.

Werner Keil wrote on 11/29/17 08:54 AM:

Hi,

I spoke with David Delabassee yesterday after his Java EE talk at JVM-Con. He sounded quite reluctant of a MR. So better wait for EE4J.

However, if you look at JSON-P, at least 2 "patch" releases were published officially to MavenCentral without a MR:
https://search.maven.org/#artifactdetails%7Cjavax.json%7Cjavax.json-api%7C1.1.2%7Cbundle

So this seems possible. For slightly different reasons (there the Maintenance Lead is completely inactive and unavailable for 2 years, more like what EE 8 had in 2016;-/) we also did a patch release at JSR 354. However both patch releases only contain tiny things, sometimes just a typo in the JavaDoc or a JUnit test not properly annotated, etc. This is not something for any structural change. If it is also adding or changing an annotation or fixing an accidential "magic number" I would suggest exploring the way JSR 374 did it already.

Werner


Werner Keil
 

I hope everyone is clear, that javax.json-api is the API/Spec, not implementation of JSR 374?
I asked Dmitry, if they were intended to be merged into the EE4J project or a fix/Patch, etc. of Java EE 8, but those changes in JSON-P were done without MR to the API, not the Glassfish RI (which was probably updated, too)


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


Will Hopkins
 

I can't speak to what was done with JSON-P, but I think Bill's point is that any changes to the spec/api at this point need to follow the JCP process, or they aren't "official" -- they can't be considered part of any recognized standard or specification.

It's possible the changes may eventually be merged into an MR, or EE4J under the Eclipse process, but anyone relying on the them now is: a) taking a chance that the changes won't make it into any future standard; and, b) needs to understand that any products built on the new changes won't be EE 8 compliant.

Having discussed this some internally, the consensus here is that we think the best path forward is to wait until JSR-375 is migrated to Eclipse/EE4J, then make changes on a branch in preparation for an eventual MR/release.

The first batch of Java EE projects is currently in process being migrated to Eclipse. JSR-375 can be in batch #2. It's hard to predict exactly when that will happen, since this is a new process, but JSR-375 is pretty clean from the standpoint of 3rd party dependencies and licensing requirements, so we expect the migration to go smoothly. We can't commit a specific date for migration, but we would expect it to be sometime in Q1/2018; with luck, it might be early in the quarter.

After migration, changes still can't be made to the "mainline", as the first task once everything's migrated over is to ensure that all the projects, and EE8, can still be built, including TCKs, and that the TCKs run and pass. Only after EE8 is confirmed to be fully and correctly migrated can further changes be made.

That said, changes can be made on a project branch as soon as the code repos are up -- so work could begin under the Eclipse rules. Assuming that the Eclipse rules allow for publishing intermediate works, an unofficial update could be published, and eventually incorporated into an official MR/release. All in all, this seems like the most expedient/quickest way to get changes to the API released.

Does that seem reasonable to folks?

Will


On 11/30/2017 08:59 AM, Werner Keil wrote:
I hope everyone is clear, that javax.json-api is the API/Spec, not implementation of JSR 374?
I asked Dmitry, if they were intended to be merged into the EE4J project or a fix/Patch, etc. of Java EE 8, but those changes in JSON-P were done without MR to the API, not the Glassfish RI (which was probably updated, too)

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Developer Experience
35 Network Drive, Burlington, MA 01803


Arjan Tijms
 

Hi,

There’s some things that could indeed go into an extended RI, but the API is just as frozen for the RI as for others.

I don’t know at this point if it’s possible to release new RI versions easily. I’m still locked out from the Soteria master and I certainly don’t have the credentials required to do a Soteria release anymore.

That’s a bit of an issue. For my or our own library I can commit to master and I would not be locked out, plus I can do Maven (central) releases for that.

That’s a very big advantage for an own independent library.

Kind regards,
Arjan Tijms


On Thursday, November 30, 2017, Guillermo González de Agüero <z06.guillermo@...> wrote:
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


Will Hopkins
 

Access to the branches shouldn't be an issue -- I can open it up or merge changes as needed.

More of a problem is publishing to maven.java.net. I don't know how to get the maven release plugin to do point releases, and the manual tweaking required even with the release plugin is non trivial (since it doesn't update everything you'd want it to).

I've been thinking it might be easier to just tweak release numbers manually, and publish directly, but I haven't yet taken the time to figure out how to do that. It probably just requires invoking the right targets/goals, but a simple deploy won't be enough -- the jars need to be signed, or they won't upload to maven.java.net.

I will say that, while we could theoretically make changes to the existing repo(s), folks here would prefer we don't, because it creates a moving target for migration.

An independent library is also an option; the issue there is making sure the IP can be cleanly contributed back to EE4J. IP ownership needs to be clear, and the owner needs to be willing/able to contribute it.

If we're talking about RI-only changes, and if time is really that critical, the best approach might be to work in the existing soteria repo. But if we can wait until after the holidays, we might have a clearer picture about when we could get into Eclipse and publish from there.

Will


On 11/30/2017 02:27 PM, Arjan Tijms wrote:
Hi,

There’s some things that could indeed go into an extended RI, but the API is just as frozen for the RI as for others.

I don’t know at this point if it’s possible to release new RI versions easily. I’m still locked out from the Soteria master and I certainly don’t have the credentials required to do a Soteria release anymore.

That’s a bit of an issue. For my or our own library I can commit to master and I would not be locked out, plus I can do Maven (central) releases for that.

That’s a very big advantage for an own independent library.

Kind regards,
Arjan Tijms


On Thursday, November 30, 2017, Guillermo González de Agüero <z06.guillermo@...> wrote:
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

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Developer Experience
35 Network Drive, Burlington, MA 01803


Guillermo González de Agüero
 

Thanks a lot Will for taking care of this.

That second batch of project donations would mean there's a proposal for an Eclipse project, which is far away from a repository we can contribute to, right? Please correct me if I'm wrong.

If that's the case, it might be too much time until a release can be made IMO.


Regards,

Guillermo González de Agüero

El jue., 30 nov. 2017 21:19, Will Hopkins <will.hopkins@...> escribió:
Access to the branches shouldn't be an issue -- I can open it up or merge changes as needed.

More of a problem is publishing to maven.java.net. I don't know how to get the maven release plugin to do point releases, and the manual tweaking required even with the release plugin is non trivial (since it doesn't update everything you'd want it to).

I've been thinking it might be easier to just tweak release numbers manually, and publish directly, but I haven't yet taken the time to figure out how to do that. It probably just requires invoking the right targets/goals, but a simple deploy won't be enough -- the jars need to be signed, or they won't upload to maven.java.net.

I will say that, while we could theoretically make changes to the existing repo(s), folks here would prefer we don't, because it creates a moving target for migration.

An independent library is also an option; the issue there is making sure the IP can be cleanly contributed back to EE4J. IP ownership needs to be clear, and the owner needs to be willing/able to contribute it.

If we're talking about RI-only changes, and if time is really that critical, the best approach might be to work in the existing soteria repo. But if we can wait until after the holidays, we might have a clearer picture about when we could get into Eclipse and publish from there.

Will



On 11/30/2017 02:27 PM, Arjan Tijms wrote:
Hi,

There’s some things that could indeed go into an extended RI, but the API is just as frozen for the RI as for others.

I don’t know at this point if it’s possible to release new RI versions easily. I’m still locked out from the Soteria master and I certainly don’t have the credentials required to do a Soteria release anymore.

That’s a bit of an issue. For my or our own library I can commit to master and I would not be locked out, plus I can do Maven (central) releases for that.

That’s a very big advantage for an own independent library.

Kind regards,
Arjan Tijms


On Thursday, November 30, 2017, Guillermo González de Agüero <z06.guillermo@...> wrote:
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

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Developer Experience
35 Network Drive, Burlington, MA 01803


Werner Keil
 

Will/all,

I'm not sure, what Oracle plans for Java EE 8, but JTA just launched a MR 6 and that's clearly not yet targeting EE4J either:
https://jcp.org/aboutJava/communityprocess/maintenance/jsr907/index6.html

If there was a bug that could compromise security, I would say let's do what's necessary, either a MR or Patch release. For everything else we can wait for later.

Regards,
Werner


Will Hopkins
 

Inline.

On 11/30/2017 03:26 PM, Guillermo González de Agüero wrote:
Thanks a lot Will for taking care of this.

That second batch of project donations would mean there's a proposal for an Eclipse project, which is far away from a repository we can contribute to, right? Please correct me if I'm wrong.

I'd say it's more than a proposal -- JSR-375 will definitely be moving to Eclipse as soon as we can make it happen.

If that's the case, it might be too much time until a release can be made IMO.

Perhaps. I can't guarantee a timeframe more precisely than Q1/2018, but it could possibly come in sooner than that. It really depends on the urgency of the proposed changes, and I don't have a good feel for that as yet.



Regards,

Guillermo González de Agüero

El jue., 30 nov. 2017 21:19, Will Hopkins <will.hopkins@...> escribió:
Access to the branches shouldn't be an issue -- I can open it up or merge changes as needed.

More of a problem is publishing to maven.java.net. I don't know how to get the maven release plugin to do point releases, and the manual tweaking required even with the release plugin is non trivial (since it doesn't update everything you'd want it to).

I've been thinking it might be easier to just tweak release numbers manually, and publish directly, but I haven't yet taken the time to figure out how to do that. It probably just requires invoking the right targets/goals, but a simple deploy won't be enough -- the jars need to be signed, or they won't upload to maven.java.net.

I will say that, while we could theoretically make changes to the existing repo(s), folks here would prefer we don't, because it creates a moving target for migration.

An independent library is also an option; the issue there is making sure the IP can be cleanly contributed back to EE4J. IP ownership needs to be clear, and the owner needs to be willing/able to contribute it.

If we're talking about RI-only changes, and if time is really that critical, the best approach might be to work in the existing soteria repo. But if we can wait until after the holidays, we might have a clearer picture about when we could get into Eclipse and publish from there.

Will



On 11/30/2017 02:27 PM, Arjan Tijms wrote:
Hi,

There’s some things that could indeed go into an extended RI, but the API is just as frozen for the RI as for others.

I don’t know at this point if it’s possible to release new RI versions easily. I’m still locked out from the Soteria master and I certainly don’t have the credentials required to do a Soteria release anymore.

That’s a bit of an issue. For my or our own library I can commit to master and I would not be locked out, plus I can do Maven (central) releases for that.

That’s a very big advantage for an own independent library.

Kind regards,
Arjan Tijms


On Thursday, November 30, 2017, Guillermo González de Agüero <z06.guillermo@...> wrote:
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

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Developer Experience
35 Network Drive, Burlington, MA 01803

-- 
Will Hopkins | WebLogic Security Architect | +1.781.442.0310
Oracle Developer Experience
35 Network Drive, Burlington, MA 01803