Make interface type available to providers

[pavolloffay]

Use case:
Provider could use annotations on the interface to configure its behavior. For example tracing integration could be disabled if @Traced(false) is added on the interface. Or it could add custom meta-data - tags specified in that annotation to the span created in the client.

This is blocking eclipse/microprofile-opentracing#102

[kenfinnigan]

Where would such information be made available?

Not sure I'm understanding what's required and how.

[pavolloffay]

Let's say I have this client:

@Traced
@TracedTags({"foo": "bar"})
@Path("/")
interface Service {
  @GET
  @Path("/get")
   get();
}

It would mean that the client is traced and the tracing integration would add foo:bar to the span created for the method invocation. Generally speaking there could be any annotation, important is that the Service.class should be available to the provider/feature class which is added to the client.

The Service.class interface could be made available in
javax.ws.rs.core.Coonfiguration.getProperty("mp.rest.client.interface"). Which is accessible in Feature and ClientRequestContext.

[andymc12]

Talking with @pavolloffay - it sounds like the ideal solution would be to have a RestClientListener that is invoked with the client itself is created (as opposed to the RestClientBuilderListener which is invoked when the builder is created). The RestClientListener's onNewClient method should include the rest client interface class - something like:
void onNewClient(Class<?> clientInterface, RestClientBuilder builder)

The RestClientListener implementations should be registered using the ServiceLoader pattern - similar to RestClientBuilderListener.

[pavolloffay]

@andymc12 I have more thoughts on the issue.

It would be great if a provider(e.g. filter) would have access to the method of the interface(which means it has an access to the interface itself). Then an annotation can be used to change a behavior of the method e.g. @Traced(false) on the specific method rather than on the whole client.

[andymc12]

@pavolloffay @kenfinnigan I think this request makes sense. What do you guys think of something like:

public interface RestClientRequestContext extends ClientRequestContext {

    Method getInvokedMethod();
}

...

public interface RestClientRequestFilter {

    void filter(RestClientRequestContext requestContext) throws IOException;
}

[pavolloffay]

If I get it correctly then users can use ClientRequestFilter or RestClientRequestFilter to basically do the same thing? Shouldn't we instead provide the Method in request attributes under some key? Or keep proposed RestClientRequestContext which would be passed into jaxrs ClientRequestFilter. Implementation could use instanceof on the context fo find out the type.

From these two putting the method into attributes seems easier to implement.

[andymc12]

Sure, we could put the Method object in the properties obtainable by ClientRequestContext.getProperty(...) - something like org.eclipse.microprofile.rest.client.invokedMethod.

[pavolloffay]

It sounds good, Will it be done in 1.2?

[andymc12]

@pavolloffay - yes, that's the plan. Thanks!

[andymc12]

@pavolloffay - are you ok with me closing this issue? There are effectively two changes here:

1. A new RestClientListener API which alerts when an actual client impl is creating (similar to the previous RestClientBuilderListener).
2. A new property that provides the java.lang.reflect.Method of the invoked Rest Client interface method available via the ClientRequestContext on client request/response filters.

[pavolloffay]

Thanks, @andymc12. It looks fine to me. I will just add pointers here:

• https://github.com/eclipse/microprofile-rest-client/blob/master/api/src/main/java/org/eclipse/microprofile/rest/client/spi/RestClientListener.java#L44
• https://github.com/eclipse/microprofile-rest-client/blob/master/spec/src/main/asciidoc/providers.asciidoc#clientrequestfilter

When do you plan to cut a release with this changes? I would like to start building OT integration with this.

[andymc12]

When do you plan to cut a release with this changes? I would like to start building OT integration with this.

@pavolloffay Our tentative plan is to release MP Rest Client 1.2 in 4Q2018. I say tentative, because the last I heard, the next release of the overall MicroProfile spec is scheduled for 1Q2019 - so it's possible that MP Rest Client 1.2 will not be released until then.

In the mean time... I don't know what the policy for "early-access" releases are. At this point, we are not in good shape to cut a release candidate, but maybe we could cut some sort of alpha or beta release? @kenfinnigan what do you think?

[pavolloffay]

I would like to use this feature in the next OT version, which should be also included in the overall spec. If you can cut a release earlier it would give us more time to develop and test. If you cut it just before the overall release there will be a short time for us to integrate.

[pavolloffay]

@andymc12 @kenfinnigan any news on the release schedule?

[andymc12]

@pavolloffay sorry for the slow reply - yes, we just published a milestone release with these changes included. You can see more info at the MP Google Group post:
https://groups.google.com/forum/#!topic/microprofile/y_yS1qtpiJQ

[pavolloffay]

This is great thank you! This ticket can be closed.