Hi Pavol,
sorry for the late reply. Weinan is now having a look at this and I believe he's getting back to you soon.

Cheers
Alessio

On Fri, Nov 24, 2017 at 1:38 PM, Pavol Loffay <ploffay@redhat.com> wrote:
I have tried to register ClientRequestFilter, DynamicFeature to ResteasyProviderFactory.getInstance(). None of these were triggered in the client. Maybe because client builder is by default using:
LocalResteasyProviderFactory(ResteasyProviderFactory.newInstance())  see https://github.com/resteasy/Resteasy/blob/master/resteasy-client/src/main/java/org/jboss/resteasy/client/jaxrs/ResteasyClientBuilder.java#L360

When I set the provider factory explicitly registered filters are executed. 

Do you have any idea?  


We also need to use different ExecutorService as I have mentioned in the first email. 
I have extended ResteasyClientBuilder and defined service/SPI pointing to that impl;. It worked for resteasy on Jetty but not in Wildly swarm fraction. However I am not sure how reliable this is.


Pavol



On Wed, Nov 22, 2017 at 6:45 PM, Pavol Loffay <ploffay@redhat.com> wrote:
I have also noticed that response code in servlet filter for an unmapped exception is 200, when the final response code returned to the client is 500. Where could I get the final response code? 

On Wed, Nov 22, 2017 at 6:33 PM, Pavol Loffay <ploffay@redhat.com> wrote:
Thanks Alessio,

I run into another problem now tracing related. I am using servlet filter to catch exceptions thrown from handlers. If the handler is async I get this https://pastebin.com/SxNGUVc0 and the exception 
is not propagated to the filter (in Jersey it is propagated, CXF has the same behaviour as resteasy). 

Do you know how could I catch this exception?

Regards,

On Tue, Nov 21, 2017 at 6:02 PM, Alessio Soldano <asoldano@redhat.com> wrote:
Hi Pavol,
as mentioned on hipchat, an idea could be to rely on the ResteasyProviderFactory (which has a getInstance static method) and install a dynamic client feature in it (e.g. using registerProviderInstance(Object obj) method).
Perhaps you can try that and see if it fits your scenario.
For the executor, I'm afraid I don't see an already existing solution, besides having your own ClientBuilder that overrides the executorService setup; perhaps we can make this configurable in the ResteasyProviderFactory, though.

If someone from the team has further idea, just reply ;-)
Cheers
Alessio


On Tue, Nov 21, 2017 at 5:22 PM, Pavol Loffay <ploffay@redhat.com> wrote:
Hi, 

I am looking at microprofile-opentracing integration for Wildfly Swarm. Briefly, it is a distributed tracing for JAX-RS both server and client. 

Issue [1] describes what is necessary. But I will repeat here:

Server
1. register server jax-rs filters (no problem, server features are auto-discovered)
2. use servlet filter to finish the span and log any exception to the span - because jax-rs filters do not capture exceptions

Client
1. register tracing filters
2. use OpenTracing-aware ExecutorService - it's needed for async API to correctly propagate parent.
(3.) TCK is not defined yet. However, if they want to create spans for UnknownHostException then we cannot use jax-rs client filters because they are not executed. Network attempt happens before the filter when the exception is thrown. To solve this we have to implement tracing in resteasy or supply apache HC with tracing filters enabled (it also has some problems).


The biggest issue is with client because we need `ClientBuilder.newBuilder()` to return client/builder with enabled tracing.





--

PAVOL LOFFAY

Red Hat Česká republika

Purkyňova 115 TPB-B 612 00 Brno

M: +421948286055    




--

PAVOL LOFFAY

Red Hat Česká republika

Purkyňova 115 TPB-B 612 00 Brno

M: +421948286055    




--

PAVOL LOFFAY

Red Hat Česká republika

Purkyňova 115 TPB-B 612 00 Brno

M: +421948286055