Date   

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


Re: Java EE Security.Next

Werner Keil
 

Yes, nobody should bother creating another Java EE Security API organization on GitHub again ;-)
Some JSRs have already been contributed, a few others are pending, but already mentioned. Mostly those that already have an Eclipse RI like EclipseLink.
It's odd, Security has not been mentioned, but people at Oracle like Dmitry, Ed or Will if he's involved can only do some of these at a time. The whole of Glassfish is not yet migrated and it may take longer due to a larger code base. 375 is relatively new, but dependencies like JASPIC could be a little more complex than e.g. JSON-P with zero external dependencies. 
While JSF was contributed, Servlet itself wasn't, so it's not the only EE 8 relevant JSR that has not been touched yet.

Werner


Re: Java EE Security.Next

Werner Keil
 

Now that several existing JSRs like 374 started with proposals to EE4J, I wonder what keeps this JSR from doing the same?
Obvious bugs or smaller improvements without introducing whole new API elements are usually natural for MRs, and based on what we heard, Oracle and other vendors should upgrade their Java EE products to use Java EE 8, so they will use 375 and Soteria in all relevant  profiles (Full and Web according to http://www.oracle.com/technetwork/java/javaee/tech/index.html) so if say SAP Cloud (https://blogs.sap.com/2017/07/27/sap-cloud-platform-is-java-ee-7-web-profile-certified/ seems using mostly TomEE 7) wants to certify against Java EE 8 then we should see either TomEE or even SAP utilize JSR 375 via its Identity Management for the Cloud to do so ;-)
Same for other Java EE 7 compatible vendors who wish to upgrade. It is possible one or the other might skip it and aim directly at EE4J but there is no definitive answer as to whether it'll offer a similar compatibility assurance or certification. 

So for important fixes or problems there should be at least one or the other MR of JSR 375, but similar to what other JSRs did, it should be very easy to fork/contribute a project to EE4J, too.
Ed who's been in charge of many things here already is one of the project leads for JSON Processing: https://projects.eclipse.org/proposals/eclipse-json-processing
So he is at Eclipse/EE4J, Ivar another EG member who also spread the word about JSR 375 is currently the PMC Chair, David also another EG member represents Tomitribe in the PMC. So does Arjan's company Payara. It should be easy to find additional contributors and project leads, if the model of sharing it among 2-3 contributing members is also found appropriate for this project. Given Arjan's contribution to 375 so far, he seems like a good candidate to do this for Payara. Almost every current EG member(company) is involved in either EE4J, MicroProfile or other Eclipse projects and committer already. Others at least signed the ECA which is what current contributors would need to contribute in this new environment. 

Regards,
Werner


Re: Java EE Security.Next

Guillermo González de Agüero
 

We should definitely wait for Will/Oracle input beforr creating a new branch for thid on the official repo. But if they are ok with that, I prefer it over the external organization.


El dom., 26 nov. 2017 20:50, Arjan Tijms <arjan.tijms@...> escribió:
p.s.

I checked the githib/javaee repos, and the branches still seem to be open to be created.

So for the mentioned experimental next API, shall I create two branches in https://github.com/javaee/security-soteria and https://github.com/javaee/security-api or shall I fork both to a new org that's open to all previous committers?


Re: Java EE Security.Next

Rudy De Busscher
 

I think a 'fork' to a new organization is safer. It indicates better that is an initiative of some of the EG members and associate members (or anyone else who wants to drive this forward)

On 26 November 2017 at 20:50, Arjan Tijms <arjan.tijms@...> wrote:
p.s.

I checked the githib/javaee repos, and the branches still seem to be open to be created.

So for the mentioned experimental next API, shall I create two branches in https://github.com/javaee/security-soteria and https://github.com/javaee/security-api or shall I fork both to a new org that's open to all previous committers?



Re: Java EE Security.Next

Arjan Tijms
 

p.s.

I checked the githib/javaee repos, and the branches still seem to be open to be created.

So for the mentioned experimental next API, shall I create two branches in https://github.com/javaee/security-soteria and https://github.com/javaee/security-api or shall I fork both to a new org that's open to all previous committers?


Re: Java EE Security.Next

Arjan Tijms
 

On Sun, Nov 26, 2017 at 11:23 am, Rudy De Busscher wrote:
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.
Indeed, so wondering what the best place for such shared experimenting could be. Maybe a branch such as Guillermo mentioned, or now that I think of it, a fork (as-in, a GitHub fork) for doing experiments in, and then from there do PRs back if/when possible.

Kind regards,
Arjan Tijms


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



Re: Java EE Security.Next

Guillermo González de Agüero
 

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


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:

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


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


Re: JCP Award 2017

Will Hopkins
 

This is awesome! Great to have this kind of recognition for the JSR. Disappointed I couldn't receive it in person, but I've no doubt Ivar represented us ably.

On 10/03/2017 01:34 PM, Guillermo González de Agüero wrote:
Congratulations everyone and thanks Werner for letting us know!

El mar., 3 de octubre de 2017 17:03, Werner Keil <werner.keil@...> escribió:
Dear All,

The JCP page has not been updated yet, but JSR 375 won the JCP Award for Most Significant JSR as announced at the JCP Party last night:
https://jcp.org/en/press/news/awards/2017award_nominees

Ivar who also talks about it today took it on behalf of the EG.

Will should get it, also a little reward for not being able to take it in person and join us this year ;-)

Congratulations everyone, especially Arjan who contributed so much. I trust you'll also be nominated in other categories. Otavio won in the member category this year, after having done so in other categories like Adopt-a-JSR earlier. 

Glad this JSR won the award, it might give it a bit more recognition and awareness on conferences other than JavaOne.

Kind Regards,
Werner

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


Re: JCP Award 2017

Guillermo González de Agüero
 

Congratulations everyone and thanks Werner for letting us know!


El mar., 3 de octubre de 2017 17:03, Werner Keil <werner.keil@...> escribió:
Dear All,

The JCP page has not been updated yet, but JSR 375 won the JCP Award for Most Significant JSR as announced at the JCP Party last night:
https://jcp.org/en/press/news/awards/2017award_nominees

Ivar who also talks about it today took it on behalf of the EG.

Will should get it, also a little reward for not being able to take it in person and join us this year ;-)

Congratulations everyone, especially Arjan who contributed so much. I trust you'll also be nominated in other categories. Otavio won in the member category this year, after having done so in other categories like Adopt-a-JSR earlier. 

Glad this JSR won the award, it might give it a bit more recognition and awareness on conferences other than JavaOne.

Kind Regards,
Werner


Re: JCP Award 2017

Arjan Tijms
 

Hi,

This is super good news! The JSR also seems to be appreciated by reviewers/bloggers from IBM, jaxenter, tss, and more, so even though we maybe only got half in of what we wanted it's still very well received it seems :)

I haven't interacted with Otavio much, but from what I've seen he's an amazing JCP member so no shame in "losing" from such an outstanding participant ;)

Thanks again to everyone who helped JSR 375 to where it is today :)

Kind regards,
Arjan Tijms


JCP Award 2017

Werner Keil
 

Dear All,

The JCP page has not been updated yet, but JSR 375 won the JCP Award for Most Significant JSR as announced at the JCP Party last night:
https://jcp.org/en/press/news/awards/2017award_nominees

Ivar who also talks about it today took it on behalf of the EG.

Will should get it, also a little reward for not being able to take it in person and join us this year ;-)

Congratulations everyone, especially Arjan who contributed so much. I trust you'll also be nominated in other categories. Otavio won in the member category this year, after having done so in other categories like Adopt-a-JSR earlier. 

Glad this JSR won the award, it might give it a bit more recognition and awareness on conferences other than JavaOne.

Kind Regards,
Werner


Re: Release 1.0 in Maven Central and its dependency tree

Will Hopkins
 

The other thing you can do is build with "mvn -P release". That's how the 1.0 implementation jar was built with a dependency on the 1.0 final API jar.

Maven doesn't make it easy to release things that also need to be built in snapshot mode, and the release plugin is helpful in someways but unhelpful in others. If anybody has any ideas how to code the pom file so it works better I'm open to suggestions. Meanwhile I'll figure out what the options are for publishing an updated release and publish something that has a 1.0 API dependency in snapshot mode (probably not until sometime next week -- taking vacation this week).

Will

On 09/21/2017 07:59 PM, Ashley Richardson wrote:
Hi,

Specifying the API version at 1.0 does indeed fix the dependency and build problem.

I'll just add a Github issue reflecting my original email to the Soteria repository so its at least documented and tracked.

Regards,

Ashley Richardson

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


Re: Release 1.0 in Maven Central and its dependency tree

Ashley Richardson
 

Hi,

This issue (and workaround) is now logged as 193: https://github.com/javaee/security-soteria/issues/193

Regards,

Ashley Richardson


Re: Release 1.0 in Maven Central and its dependency tree

Ashley Richardson
 

Hi,

Specifying the API version at 1.0 does indeed fix the dependency and build problem.

I'll just add a Github issue reflecting my original email to the Soteria repository so its at least documented and tracked.

Regards,

Ashley Richardson


Re: Release 1.0 in Maven Central and its dependency tree

Arjan Tijms
 

Hi,

At a quick glance, that does't look quite good at all :O

The Java EE 8 samples project uses the API 1.0 pom without any issues. Both local and on a clean travis environment it could be resolved.

See https://github.com/javaee-samples/javaee8-samples/blob/1ddfa41dd54582fea518124c3d1f307b61f57396/pom.xml#L149

Payara 5 also used the 1.0 version, but includes both API and Implementation artefacts:

See https://github.com/payara/Payara/blob/Payara-5/appserver/pom.xml#L670

The workaround therefor may be to specify both API and Implementations dependencies in your pom. Not ideal, of course. But could you perhaps try that?

Kind regards,
Arjan Tijms


Release 1.0 in Maven Central and its dependency tree

Ashley Richardson
 

Hi,

Now that the 1.0 release is posted on Maven Central, can someone just check if I am following the POMs completely wrong:

org.glassfish.security:javax.security.enterprise 1.0 contains the following dependency:

<dependency>
   <groupId>javax.security.enterprise</groupId>
   <artifactId>javax.security.enterprise-api</artifactId>
   <version>${api_dependency_version}</version>
</dependency>

http://central.maven.org/maven2/org/glassfish/soteria/javax.security.enterprise/1.0/javax.security.enterprise-1.0.pom

That ${api_dependency_version} comes from the parent POM at org.glassfish.soteria:parent 1.0
http://central.maven.org/maven2/org/glassfish/soteria/parent/1.0/parent-1.0.pom

In that parent POM that property is listed as 1.1-b01-SNAPSHOT

However on Maven Central that version does not exist and only versions b05-b11 plus 1.0 exist
http://central.maven.org/maven2/javax/security/enterprise/javax.security.enterprise-api/

I only noticed this as I am updating a project to use Soteria 1.0 from b07 and the build no longer runs due to dependencies not being found.

Can someone please check my train of logic and if I did follow this correctly what can we do to fix it up?

Regards,

Ashley Richardson

41 - 60 of 736