MicroProfile JWT - TCK puts microprofile-config.properties in a WAR's META-INF?

34 views
Skip to first unread message

Arjan Tijms

unread,
Dec 12, 2019, 8:39:29 AM12/12/19
to Eclipse MicroProfile

Hi,


I'm currently busy with adding JWT support to Piranha, and I noticed that PublicKeyAsPEMTest adds microprofile-config.properties to a WAR's META-INF, which is not an officially supported location, is it?


See https://github.com/eclipse/microprofile-jwt-auth/blob/master/tck/src/test/java/org/eclipse/microprofile/jwt/tck/config/PublicKeyAsPEMTest.java#L87


Running the test prints this which makes it clear:


WebArchive: PublicKeyAsPEMTest.war:

/META-INF/

/META-INF/MPJWTTESTVERSION

/META-INF/microprofile-config.properties

/WEB-INF/

/WEB-INF/classes/

/WEB-INF/classes/publicKey.pem

/WEB-INF/classes/org/

/WEB-INF/classes/org/eclipse/

/WEB-INF/classes/org/eclipse/microprofile/

/WEB-INF/classes/org/eclipse/microprofile/jwt/

/WEB-INF/classes/org/eclipse/microprofile/jwt/tck/

/WEB-INF/classes/org/eclipse/microprofile/jwt/tck/config/

/WEB-INF/classes/org/eclipse/microprofile/jwt/tck/config/PublicKeyEndpoint.class

/WEB-INF/classes/org/eclipse/microprofile/jwt/tck/config/SimpleTokenUtils.class

/WEB-INF/classes/org/eclipse/microprofile/jwt/tck/container/

/WEB-INF/classes/org/eclipse/microprofile/jwt/tck/container/jaxrs/

/WEB-INF/classes/org/eclipse/microprofile/jwt/tck/container/jaxrs/TCKApplication.class

/WEB-INF/beans.xml


I somehow missed this last time around when I was looking at the test. Am I missing something here, or is this just wrong?

Ondro Mihályi

unread,
Dec 13, 2019, 2:56:14 AM12/13/19
to Eclipse MicroProfile
The same thing happened in OpenAPI, which specified an additional location for config properties. This is a little bit bit eeky and confusing that a spec not related to config specifies an additional config source. And here we see it again. Not a good pattern IMHO.

Things like these should be optional at the impl level and not prescribed by random specs.

Ondro

Arjan Tijms

unread,
Dec 13, 2019, 5:23:34 AM12/13/19
to Eclipse MicroProfile
Hi,

Indeed, we saw the same in OpenAPI.

In this case however the spec doesn't say anything about it, but the TCK tests just put it there. My guess for now is that it's just a bug, and the test code should have used addResource() instead of addAsManifestResource.

Scot?

Sergey Beryozkin

unread,
Dec 13, 2019, 5:54:32 AM12/13/19
to microp...@googlegroups.com
It is a not a bug and this test code has been around for a while.
To be honest I don't see anything wrong with the dedicated specs supporting more locations beyond those which are known at the lower MP Config level.

That said, perhaps there is a time to add this to the MP Config as one of the officially recognized locations ?

Cheers, Sergey



--
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 view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/2f620c5b-752a-42dd-895d-f47ac17b43ee%40googlegroups.com.

arjan tijms

unread,
Dec 13, 2019, 7:03:23 AM12/13/19
to microp...@googlegroups.com
Hi,

I think it might be a bug, if not it’s slightly worrying.

The code has been around since 1.1/1.1.1. That test wasn’t in 1.0 at all.

The problem is I was implementing and certifying MP JWT. I used SmalRye for MP config. It, of course, didn’t picked up that file from war/meta-inf.

There isn’t any spec rule anywhere that says it should. The MP JWT spec doesn’t state this either.

It’s just the TCK depending on a non-specified and therefore non-portable feature.


On Friday, December 13, 2019, Sergey Beryozkin <sbia...@redhat.com> wrote:
It is a not a bug and this test code has been around for a while.
To be honest I don't see anything wrong with the dedicated specs supporting more locations beyond those which are known at the lower MP Config level.

That said, perhaps there is a time to add this to the MP Config as one of the officially recognized locations ?

Cheers, Sergey



On Fri, Dec 13, 2019 at 10:23 AM Arjan Tijms <arjan...@gmail.com> wrote:
Hi,

Indeed, we saw the same in OpenAPI.

In this case however the spec doesn't say anything about it, but the TCK tests just put it there. My guess for now is that it's just a bug, and the test code should have used addResource() instead of addAsManifestResource.

Scot?

On Friday, December 13, 2019 at 8:56:14 AM UTC+1, Ondro Mihályi wrote:
The same thing happened in OpenAPI, which specified an additional location for config properties. This is a little bit bit eeky and confusing that a spec not related to config specifies an additional config source. And here we see it again. Not a good pattern IMHO.

Things like these should be optional at the impl level and not prescribed by random specs.

Ondro

--
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+unsubscribe@googlegroups.com.

--
You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/nm7Ph0XK_UU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAMsYBfXWLeJcLQgsyVw5xUL55WPcZBGxhytC6PguBhdvifkh%3Dg%40mail.gmail.com.

Sergey Beryozkin

unread,
Dec 13, 2019, 7:21:03 AM12/13/19
to microp...@googlegroups.com
Hi

No, should not be a problem IMHO. What would be of concern to me if the specs were restrained only by those locations which were introduced in MP Config few years ago. It would be not good if at some stage we were not allowed to say that 'mp-jwt.properties' can not be used as a source, just an example as every higher level spec may find it useful to check the locations which work well in the relevant contexts.

You are right there should've been more text support around it but it is not there, yet all the implementations claiming a compliance with MP JWT 1.1.1 do support this source :-).
Rather than looking at it as a 'bug' I'd consider viewing as an opportunity to add an explicit recommendation to MP Config (since OpenApi is also in the same space) that meta-inf locations should also be recognized. Or just update the MP JWT text that na extra source is recognized at ist level.

Cheers, Sergey

On Fri, Dec 13, 2019 at 12:03 PM arjan tijms <arjan...@gmail.com> wrote:
Hi,

I think it might be a bug, if not it’s slightly worrying.

The code has been around since 1.1/1.1.1. That test wasn’t in 1.0 at all.

The problem is I was implementing and certifying MP JWT. I used SmalRye for MP config. It, of course, didn’t picked up that file from war/meta-inf.

There isn’t any spec rule anywhere that says it should. The MP JWT spec doesn’t state this either.

It’s just the TCK depending on a non-specified and therefore non-portable feature.

On Friday, December 13, 2019, Sergey Beryozkin <sbia...@redhat.com> wrote:
It is a not a bug and this test code has been around for a while.
To be honest I don't see anything wrong with the dedicated specs supporting more locations beyond those which are known at the lower MP Config level.

That said, perhaps there is a time to add this to the MP Config as one of the officially recognized locations ?

Cheers, Sergey



On Fri, Dec 13, 2019 at 10:23 AM Arjan Tijms <arjan...@gmail.com> wrote:
Hi,

Indeed, we saw the same in OpenAPI.

In this case however the spec doesn't say anything about it, but the TCK tests just put it there. My guess for now is that it's just a bug, and the test code should have used addResource() instead of addAsManifestResource.

Scot?

On Friday, December 13, 2019 at 8:56:14 AM UTC+1, Ondro Mihályi wrote:
The same thing happened in OpenAPI, which specified an additional location for config properties. This is a little bit bit eeky and confusing that a spec not related to config specifies an additional config source. And here we see it again. Not a good pattern IMHO.

Things like these should be optional at the impl level and not prescribed by random specs.

Ondro

--
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.

--
You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/nm7Ph0XK_UU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile...@googlegroups.com.

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAE%3D-AhC8cQzdLha2BAnFvXDXDvYimTTTvCVS7gQBcbeXP3RamA%40mail.gmail.com.

Michael Edgar

unread,
Dec 13, 2019, 7:37:32 AM12/13/19
to microp...@googlegroups.com
Looking at the Servlet spec, it seems to indicate that the <WAR Root>/META-INF directory is intended for archive tool use (version 4, section 10.6). It might be a misuse of that location to require that implementations support configuration there. MP Config requires the properties to be in META-INF on the class path, which I don't believe would be the case for <WAR Root>/META-INF (versus META-INF in WEB-INF/classes). I'm guessing that whatever is allowing current implementations to pass those tests is due to some nuance with the way the archives are being loaded by the classloader.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAMsYBfV83QJSxNGbH0e9Dd9r9DrHZchnSNbEijxpa1Hqigmn1Q%40mail.gmail.com.

Sergey Beryozkin

unread,
Dec 13, 2019, 8:07:45 AM12/13/19
to microp...@googlegroups.com
Hi

OK. May be this or that legacy spec pays some attention to this location and I appreciate MP Config has its own view on the locations but my point was it would be too restraining if the others specs were always 'afraid' to add some other source unless it was covered by MP Config...

Another example, let's say we start supporting the injection of the JWKs obtained from HTTPS. Would we need to try to update MP Config to recognize HTTPS URI as a source ? But it would not make sense at the lower level MP Config...

Cheers, Sergey

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAJ9fJk4-dwN%3Du9QOa5G6j7%2BiRXs0kMdfvarpfGZUafLSm9cc1g%40mail.gmail.com.

Arjan Tijms

unread,
Dec 13, 2019, 9:09:06 AM12/13/19
to Eclipse MicroProfile
Hi,


On Friday, December 13, 2019 at 1:21:03 PM UTC+1, Siarhei Biarozkin wrote:
No, should not be a problem IMHO. What would be of concern to me if the specs were restrained only by those locations which were introduced in MP Config few years ago.

But that's not what's happening here, is it?

For the purpose of the test it makes no difference if the config file is put in WAR/meta-inf or WAR/web-inf/classes/meta-inf. The test code just needs to pick it up, that's all.

It doesn't offer any optional location that's extra to what's being offered by MP Config. 

In order to pass the test your test code has to pick it up from WAR/meta-inf, which you can do e.g. in an extension and from the extension you put it back on the normal classpath of the archive. In order words, this accomplishes nothing but annoyance and overhead for those having to write the test runner for their product. Users still don't have an extra location they can depend on, since it's not specified in any way.



You are right there should've been more text support around it but it is not there, yet all the implementations claiming a compliance with MP JWT 1.1.1 do support this source :-).

Well, not exactly. You can simply move the file to the right location in your archive handler:

public class ConfigPropertiesAdder implements ApplicationArchiveProcessor {

    public void process(WebArchive webArchive) {
        Node metaInfConfig = webArchive.get("/META-INF/microprofile-config.properties");
        
        if (metaInfConfig != null) {
            webArchive.addAsResource(metaInfConfig.getAsset(), "META-INF/microprofile-config.properties");
            webArchive.delete("/META-INF/microprofile-config.properties");
        }
        
    }
}

So as mentioned above, it accomplishes nothing.

 
Rather than looking at it as a 'bug' I'd consider viewing as an opportunity to add an explicit recommendation to MP Config

But is that the way to force in features in the spec?

What if I had contributed a TCK test that happened to be depending on Jakarta Authentication? Then, based on that test, claim Jakarta Authentication support has to be added to the spec?

I'm not sure if that's the right way to do these things.


 
To unsubscribe from this group and stop receiving emails from it, send an email to microp...@googlegroups.com.

--
You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/nm7Ph0XK_UU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microp...@googlegroups.com.

--
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 microp...@googlegroups.com.

Arjan Tijms

unread,
Dec 13, 2019, 9:13:48 AM12/13/19
to Eclipse MicroProfile
Hi,


On Friday, December 13, 2019 at 2:07:45 PM UTC+1, Siarhei Biarozkin wrote:

Another example, let's say we start supporting the injection of the JWKs obtained from HTTPS. Would we need to try to update MP Config to recognize HTTPS URI as a source ? But it would not make sense at the lower level MP Config...

I don't think that example is really valid. If MP JWT wanted that, it can easily specify a source for that, and then the TCK can test it.

It's however weird when the TCK does something that's not specified, and not even explicitly needed at that point, and then implicitly sets spec behaviour there. 



 

Cheers, Sergey

To unsubscribe from this group and stop receiving emails from it, send an email to microp...@googlegroups.com.

--
You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/nm7Ph0XK_UU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microp...@googlegroups.com.

--
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 microp...@googlegroups.com.

--
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 microp...@googlegroups.com.

--
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 microp...@googlegroups.com.

Sergey Beryozkin

unread,
Dec 13, 2019, 9:20:31 AM12/13/19
to microp...@googlegroups.com
Hi

On Fri, Dec 13, 2019 at 2:09 PM Arjan Tijms <arjan...@gmail.com> wrote:
Hi,

On Friday, December 13, 2019 at 1:21:03 PM UTC+1, Siarhei Biarozkin wrote:
No, should not be a problem IMHO. What would be of concern to me if the specs were restrained only by those locations which were introduced in MP Config few years ago.

But that's not what's happening here, is it?

For the purpose of the test it makes no difference if the config file is put in WAR/meta-inf or WAR/web-inf/classes/meta-inf. The test code just needs to pick it up, that's all.

It doesn't offer any optional location that's extra to what's being offered by MP Config. 

In order to pass the test your test code has to pick it up from WAR/meta-inf, which you can do e.g. in an extension and from the extension you put it back on the normal classpath of the archive. In order words, this accomplishes nothing but annoyance and overhead for those having to write the test runner for their product. Users still don't have an extra location they can depend on, since it's not specified in any way.

 


You are right there should've been more text support around it but it is not there, yet all the implementations claiming a compliance with MP JWT 1.1.1 do support this source :-).

Well, not exactly. You can simply move the file to the right location in your archive handler:

public class ConfigPropertiesAdder implements ApplicationArchiveProcessor {

    public void process(WebArchive webArchive) {
        Node metaInfConfig = webArchive.get("/META-INF/microprofile-config.properties");
        
        if (metaInfConfig != null) {
            webArchive.addAsResource(metaInfConfig.getAsset(), "META-INF/microprofile-config.properties");
            webArchive.delete("/META-INF/microprofile-config.properties");
        }
        
    }
}

So as mentioned above, it accomplishes nothing.

 
Rather than looking at it as a 'bug' I'd consider viewing as an opportunity to add an explicit recommendation to MP Config

But is that the way to force in features in the spec?

What if I had contributed a TCK test that happened to be depending on Jakarta Authentication? Then, based on that test, claim Jakarta Authentication support has to be added to the spec?

I'm not sure if that's the right way to do these things.


No one is talking about forcing the things into the spec. And indeed this is not a cool location. But rather than coming down in force on this really minor issue, treat it as a bug, releasing a new version (and same with open api for consistency's sake), and spending a lot of time on it which can be better be spent on something else, I'd rather add a note like "Please not that MP JWT resources might be located in war's meta-inf but you are strongly encouraged to use MP Config locations"/etc and move on.
It is really not worth a major group discussion IMHO :-)
 
Cheers, Sergey
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/583cfa77-32b1-41d3-bf41-3a58136c9579%40googlegroups.com.

Sergey Beryozkin

unread,
Dec 13, 2019, 9:21:53 AM12/13/19
to microp...@googlegroups.com
I agree on that one, I realized the example was somehow orthogonal...

Sergey

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/393078b3-50db-433a-8430-64b9417e0309%40googlegroups.com.

Sergey Beryozkin

unread,
Dec 13, 2019, 9:32:54 AM12/13/19
to microp...@googlegroups.com
On Fri, Dec 13, 2019 at 2:20 PM Sergey Beryozkin <sbia...@redhat.com> wrote:
Hi

On Fri, Dec 13, 2019 at 2:09 PM Arjan Tijms <arjan...@gmail.com> wrote:
Hi,

On Friday, December 13, 2019 at 1:21:03 PM UTC+1, Siarhei Biarozkin wrote:
No, should not be a problem IMHO. What would be of concern to me if the specs were restrained only by those locations which were introduced in MP Config few years ago.

But that's not what's happening here, is it?

For the purpose of the test it makes no difference if the config file is put in WAR/meta-inf or WAR/web-inf/classes/meta-inf. The test code just needs to pick it up, that's all.

It doesn't offer any optional location that's extra to what's being offered by MP Config. 

In order to pass the test your test code has to pick it up from WAR/meta-inf, which you can do e.g. in an extension and from the extension you put it back on the normal classpath of the archive. In order words, this accomplishes nothing but annoyance and overhead for those having to write the test runner for their product. Users still don't have an extra location they can depend on, since it's not specified in any way.


I don't know, maybe I'm not seeing something but here for example, no special tricks are done:



Arjan Tijms

unread,
Dec 13, 2019, 9:36:07 AM12/13/19
to Eclipse MicroProfile
On Friday, December 13, 2019 at 3:20:31 PM UTC+1, Siarhei Biarozkin wrote:
Hi

Well, that's not really the right location to look. You won't see any special tricks here done either:


In both case the code uses the config API.

What might be the case however is that in Thorntail WAR/meta-inf, happens to be on the classpath, which is not portable, or maybe Thorntail adds its own config source that, using internal proprietary code, can read from WAR/meta-inf (there are no standard APIs to read this). It could also be that the test runner (the piece of code uses to run the TCK on Thorntail) moves the file to the right location prior to starting the test.

Without anything being specified, we don't know. And that's basically my main point here ;)



Sergey Beryozkin

unread,
Dec 13, 2019, 10:13:26 AM12/13/19
to microp...@googlegroups.com
That is possible even though I could not spot it by looking through the shrinkwrap code...

Cheers, Sergey

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/fcf4c910-6681-4d2c-a4a1-cc3f0cecbf7d%40googlegroups.com.

Emily Jiang

unread,
Dec 13, 2019, 11:16:24 AM12/13/19
to Eclipse MicroProfile
Just to clarify this:

On MP Config, we said very clearly the META-INF/microprofile-config.properties on the classpath will be picked up. Obvious for .war, it will be WEB-INF/classes/META-INF/microprofile-config.properties. For .jar, it will be root/META-INF/microprofile-config.properties.

I think on building the .war, the folder of META-INF/microprofile-config.properties is placed under WEB-INF/classes/META-INF/microprofile-config.properties for maven projects for an instance. Did you look at the built .war file to inspect the final directory. By the way, I will be against the idea of requiring root/META-INF/microprofile-config.properties to be supported in MP JWT. We did not the support in MP Config based on the lessons learned from the beans.xml location. You know you will run into the priority issue.

Thanks
Emily

Sergey Beryozkin

unread,
Dec 13, 2019, 12:06:52 PM12/13/19
to microp...@googlegroups.com
Hi, thanks for this extra info,
It might be that Thorntail also does some manipulation or actually picks it up directly from META-INF but I appreciate the concern about this being formally supported. (Though the fact Thorntail supports it should definitely assure the community :-), lol)
Seriously though, we have the users looking at our code and possibly at the TCK code, and we are not 100% sure now they haven't gone ahead and done something similar in their archive customizers or indeed in similar customizers in the other implementations.

Arjan, can you please open a TCK issue (with PR ?) for Scott to comment in case some extra requirements were thought of at the time...

Thanks, Sergey

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/f3b49cf7-b1fc-4e2f-a002-1c1381307c12%40googlegroups.com.

Ondro Mihályi

unread,
Dec 14, 2019, 2:26:35 AM12/14/19
to MicroProfile
I'm in favor of relying on standard MP config sources only unless there's a need to add additional locations. OpenAPI haf thr need because they felt that the META-INF location is more transparent to some widely used tools that would manipulate the built WAR or JAR file from outside. For MP JWT I don't see any usecase yet.

If there's a usecase in MP JWT, it should be clarified in the spec document and this additional location should be also cover by a specific test case. And the spec should also specify the priority of this source. To avoid conflicts with OpenAPI, the priority should be equal in both specs. Or we can specify the source in MP config as optional and with a standard priority. Do you see now why it's complocated if specs just add their own random sources? 

We should either fix the test or have a discussion about why the extra location is needed and how to cover it in the spec and TCK properly. 

Ondro

Dňa pi 13. 12. 2019, 18:06 Sergey Beryozkin <sbia...@redhat.com> napísal(a):
You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/nm7Ph0XK_UU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CAMsYBfVZe0Qh%2BiTuVpg5OcNLGx-kbR3FO%3DPctm4a1K2se7n6og%40mail.gmail.com.

Sergey Beryozkin

unread,
Dec 15, 2019, 2:07:44 PM12/15/19
to microp...@googlegroups.com
Thanks for the feedback. Putting the case of the war/META-INF location aside for a moment, I'd like to reiterate that IMHO it would be too restraining if the dedicated specs could not differentiate so perhaps there is some scope at the MP config level to make it easy, 'ConfigLocation' SPI/etc... Let the users to have microprofile-config.properties resolved from anywhere...

As for 'war/META-INF' in the TCK test, it is not a big deal IMHO since the MP JWT implementations are now capable of handling one extra location (or at least they have become more user-friendly as they can easily handle the users mixing either addAsManifestResource or addAsWebInfResource in the test code). If one really wants to stretch it then it is possible to also suggest that 'war/META-INF' will let the tools to replace the public keys in application.properties and thus do some kind of tool-driven key rotation, but maybe it is not worth it...

In any case I proposed to Arjan to submit a TCK test PR for Scott to review. Or just leave it as is....Since it already works for all the MP JWT implementations

Cheers, Sergey

Sergey


To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/CACZTZYXoFbe-HXMm5fm-s6ZZqT9Rj7Hb%3Dvbg1QFJAU%2BAcHxmBA%40mail.gmail.com.

Alasdair Nottingham

unread,
Dec 15, 2019, 2:30:44 PM12/15/19
to microp...@googlegroups.com
It was agreed some time ago that MP doesn’t require war packaging. A few times the TCK’s have ended up relying on it, but when discovered the TCKs have been updated. 

I think specs should be able to propose things like this, but a TCK should not test for things not in the spec and the fact that implementations pass on it shouldn’t be used to claim the TCK is right despite a gap in the spec. 

If this was an agreed upon them the correct response would be a PR to update the spec. This would probably be good because it would move the discussion off email and into the PR comment thread. 

Alasdair Nottingham

On Dec 15, 2019, at 2:07 PM, Sergey Beryozkin <sbia...@redhat.com> wrote:



Arjan Tijms

unread,
Dec 16, 2019, 4:56:36 AM12/16/19
to Eclipse MicroProfile
Hi,


On Sunday, December 15, 2019 at 8:07:44 PM UTC+1, Siarhei Biarozkin wrote:
In any case I proposed to Arjan to submit a TCK test PR for Scott to review. Or just leave it as is....Since it already works for all the MP JWT implementations 

I'll submit the TCK test PR, thanks!. It "worked" for our (Piranha) implementation after we added the archive hack. Might be nice to pass without the hack ;)


Kind regards,
Arjan


 

Cheers, Sergey

Sergey


To unsubscribe from this group and stop receiving emails from it, send an email to microp...@googlegroups.com.

--
You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/nm7Ph0XK_UU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to microp...@googlegroups.com.

--
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 microp...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages