Java EE profiles and MicroProfile in context of MP-JWT

sst...@redhat.com

unread,

Aug 4, 2017, 6:09:52 PM8/4/17

to Eclipse MicroProfile

So I have had a few questions on the scope of APIs that should be tested in the MP-JWT security tests. I was thinking that the testing needed to be structured along the lines of a minimal MP-profile that just relies on the base APIs we are included in the MicroProfile 1.2 release, and then have additional sets that expand out to the Java EE profiles so that interaction between MP endpoints and other Java EE components is defined.

Apparently there is some concern about including too much in the 1.0 release. To that point, what if we defined the behaviors of the security related APIs as needed for the MicroProfile 1.2 as required, and then have a section in the specification on recommendations for the other container APIs such as servlet, ejb, jacc, etc.?

Alasdair Nottingham

unread,

Aug 7, 2017, 3:17:06 PM8/7/17

to microp...@googlegroups.com

I am concerned about talking in the spec about how JWT, servlet, ejb and other services beyond the MP subset Yet at the same time a few implementations are also going above and beyond and it would be generally useful if those that did acted in a common way.

So I think having a non-binding Appendix to provide guidelines to full EE servers is sensible but rovided it doesn't imply MP has a scope beyond CDI, and JAX-RS.

Alasdair Nottingham

On Aug 4, 2017, at 6:09 PM, sst...@redhat.com wrote:

So I have had a few questions on the scope of APIs that should be tested in the MP-JWT security tests. I was thinking that the testing needed to be structured along the lines of a minimal MP-profile that just relies on the base APIs we are included in the MicroProfile 1.2 release, and then have additional sets that expand out to the Java EE profiles so that interaction between MP endpoints and other Java EE components is defined.

Apparently there is some concern about including too much in the 1.0 release. To that point, what if we defined the behaviors of the security related APIs as needed for the MicroProfile 1.2 as required, and then have a section in the specification on recommendations for the other container APIs such as servlet, ejb, jacc, etc.?

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/821dd45c-b6c1-48c0-9000-ded9fe6c1c92%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

David Blevins

unread,

Aug 7, 2017, 5:28:17 PM8/7/17

to Eclipse MicroProfile

An Appendix is a good idea. Could we have “Appendix” tests as well? A bit of an add-on TCK for extra, non-mandatory, items?

Admittedly, being a bit loose and pragmatic on things like this is one of the things I think makes MicroProfile special. Tip-toing into the grey area rather than shying away from it.

--

David Blevins

http://twitter.com/dblevins
http://www.tomitribe.com

310-633-3852

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/F14AD9CD-179B-4C8C-AF4F-0EF777EE43D3%40gmail.com.

sst...@redhat.com

unread,

Aug 7, 2017, 6:57:37 PM8/7/17

to Eclipse MicroProfile

I don't see a point in writing up recommend behaviors without providing tests for those behaviors, regardless of whether they are optional, so that is what I was meaning by having profiles of tests that are separated into required for a specific version, and optional tests that validate whether the spec recommendations are consistent with expectations.

So yes, tests should exist for behaviors described in the spec.