MP Rest Client 1.3 RC1 Available

[Andy McCright]

Hi All,

The MP Rest Client 1.3 release candidate 1 is now available - details at:

https://github.com/eclipse/microprofile-rest-client/releases/tag/1.3-RC1

Maven coordinates:

<dependency>

    <groupId>org.eclipse.microprofile.rest.client</groupId>

    <artifactId>microprofile-rest-client-api</artifactId>

    <version>1.3-RC1</version>

</dependency>

Key features:

- Simpler configuration using configKeys - allowing multiple client interfaces to be configured with the same configuration settings.

- SSL configuration support.

- Allow client proxies to be cast to `Closeable`/`AutoCloseable`, enabling resources to be cleaned up after use.

- Defined `application/json` to be the default MediaType if none is specified in `@Produces`/`@Consumes`.

I'll be making a few tweaks (updating OSGI package versions, release notes, etc.).  If you have any questions or concerns, please let me know.

Thanks,

Andy

[Ladislav Thon]

pá 3. 5. 2019 v 23:59 odesílatel Andy McCright <j.andrew...@gmail.com> napsal:

- Allow client proxies to be cast to `Closeable`/`AutoCloseable`, enabling resources to be cleaned up after use.

This caught my attention. I don't follow the RestClient project, so I'd like to ask: would I be able to make the client interface `extend [Auto]Closeable`, so that I don't have to cast? I guess maybe probably yes, but I don't see a definite answer in the spec.

Thanks,

LT

[Michal Szynkiewicz]

This is how I understood the idea but indeed, neither the test nor the text mentions extending Closable.

On Monday, May 6, 2019 at 9:02:40 AM UTC+2, Ladislav Thon wrote:

pá 3. 5. 2019 v 23:59 odesílatel Andy McCright <j.andre...@gmail.com> napsal:

[Ladislav Thon]

I can see implementations rejecting the client interface because it contains a method not annotated with JAX-RS annotations (inherited `close` method). So if extending [Auto]Closeable is to be permitted, I guess it should be specified. But I don't really know :-)

LT

po 6. 5. 2019 v 21:37 odesílatel Michal Szynkiewicz <mszy...@redhat.com> napsal:

--
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/87c6abcc-f4e2-49f8-b241-d74f0452ccd8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Andy McCright]

We updated the spec the text and added a couple of TCK tests to clarify that the user can have their interface extend Closeable or AutoCloseable (or if it doesn't, then they can still cast it to one or the other).  You can see the changes here:  https://github.com/eclipse/microprofile-rest-client/pull/193/files

Thanks for brining this up!  If you have any other questions, clarifications, etc., please let us know as soon as possible.  We're hoping to publish a final 1.3 release later this week.

Thanks again!

Andy

On Tuesday, May 7, 2019 at 1:27:59 AM UTC-5, Ladislav Thon wrote:

I can see implementations rejecting the client interface because it contains a method not annotated with JAX-RS annotations (inherited `close` method). So if extending [Auto]Closeable is to be permitted, I guess it should be specified. But I don't really know :-)

LT

po 6. 5. 2019 v 21:37 odesílatel Michal Szynkiewicz <mszy...@redhat.com> napsal:

This is how I understood the idea but indeed, neither the test nor the text mentions extending Closable.

On Monday, May 6, 2019 at 9:02:40 AM UTC+2, Ladislav Thon wrote:

pá 3. 5. 2019 v 23:59 odesílatel Andy McCright <j.andre...@gmail.com> napsal:

- Allow client proxies to be cast to `Closeable`/`AutoCloseable`, enabling resources to be cleaned up after use.

This caught my attention. I don't follow the RestClient project, so I'd like to ask: would I be able to make the client interface `extend [Auto]Closeable`, so that I don't have to cast? I guess maybe probably yes, but I don't see a definite answer in the spec.

Thanks,

LT

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

[Emily Jiang]

Thank you Andy! Please use the new instruction for the release note of Rest Client 1.3!

Thanks

Emily

[Andy McCright]

Hi All,

I am seeing some SSL TCK test failures with CXF (my compatible implementation for MP Rest Client 1.3) related to the trust store.  I suspect it may be a test bug - I can reproduce the failure with a standalone Java app using HttpURLConnection (more details on the failure and standalone app here: https://gist.github.com/andymc12/25e7a4e445a1bc7e284717b3c1bf6f9a ).

These failures seem to be occurring when the test server (based on Jetty) uses a trust store.  The other SSL tests pass fine, but the four tests where Jetty has a specified trust store (require client SSL authentication) and expect the MP Rest Client to connect with a valid certificate all fail in the same way - with a broken pipe exception.  

The schedule calls for us to publish a final release today or tomorrow, and I don't think I will be able to work out these issues in that time.  I'd like to get some feedback on what the next step should be - as I see it, we can:

1) Excluded these tests and release - we should be able to add the tests back in in a micro release (1.3.1) once we figure out the problem.

2) Pull MP Rest Client 1.3 from the June MP 3.0 release.

3) Ship MP Rest Client 1.3 without a CI that passes the full TCK.

4) Anything else?

I think 3 is probably not really an option.  So the real question is, is there any objection to excluding these tests?

Thanks,

Andy

[Andy McCright]

Hi All,

Update:  Many thanks to Michal Szynkiewicz.  He discovered what seems like a regression in the Jetty codebase.  The April 2019 version of Jetty (which I was using in CXF) seems to have a problem with SSL connections.  The November 2018 version does not have this problem.  When I switched CXF to use the older version to test with, all of the tests passed.  CXF can now be declared a compatible implementation, which means that we should be able to release on time for June.  

Thanks,

Andy