New client PreInvocationInterceptor and PostInvocationInterceptor SPI

[jansupol]

… executed around the request

Signed-off-by: Jan Supol jan.supol@oracle.com

[jansupol]

New SPI to provide ClientRequestContext and ClientResponseContext at the beginning and at the end of the client request invocation. The primary use case is to provide the contexts to set some properties before and after the request, i.e. before the ClientRequestFilter and ClientResponseFilter instances are processed, and to ensure that every instance of the new SPI interfaces (PreInvocationInterceptor && PostInvocationInterceptor) is processed, no matter the exception thrown in the request chain.

This can be particularly useful for logging, measuring and tracing the requests. The Filters are not useful, since they may not be processed at all, if ClientRequestContext#abortWith or Exception occur.

[pdudits]

This is very nice and rich API beyond what I imagined. I tried some experiments with it, and can be seen on this branch:

pdudits@7ff7e84: implementing thread-local context propagation for async() and rx() calls will be straightforward

pdudits@e9397cf: Reimplementing AsyncInterceptor without need for executorService wrapping is also simple. Only missing thing is, that the PreInvocationInterceptor doesn't know the kind of invocation that is happening, and therefore cannot be registered as top-level component, but need to wait until the client is sure, that it will invoke async request.

pdudits@ed56aca: Throwing Error in PostInvocationInterceptor hides it in suppresed exceptions. It would be better to include first throwable as a cause, as also commented on this PR.

pdudits@63c2cc3: Trying context propagation with third-party RxInvoker (RxJava) fails -- the invoker doesn't invoke the interceptor on calling thread, therefore the ultimate goal of being able to always propagate calling thread context is not met by this PR.
Do you see any way of making this possible? Or is it something that RxInvokerProviders need to support explicitly?

[jansupol]

the invoker doesn't invoke the interceptor on calling thread

Maybe some other use case would make sense - to implement something similar to RestClientBuilderListener. While it could be used by external factories to set the request, it would fit your use case, too. I admit the primary use-case for PreInvocationInterceptor is a bit different.

I monitor requests for such an interface anyway, I try to come up with some PR.

[tomas-langer]

LGTM