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(a)redhat.com&gt; 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. > > [1] https://issues.jboss.org/browse/SWARM-1691 > > > -- > > PAVOL LOFFAY > > Red Hat Česká republika <https://www.redhat.com/> > > Purkyňova 115 > <https://maps.google.com/?q=%C4%8Cesk%C3%A1+republika+Purky%C5%88ova+115&a... > TPB-B 612 00 Brno > > M: +421948286055 > <https://red.ht/sig> >

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(a)redhat.com&gt; 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(a)redhat.com&gt; > 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(a)redhat.com&gt; >> 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. >>> >>> [1] https://issues.jboss.org/browse/SWARM-1691 >>> >>> >>> -- >>> >>> PAVOL LOFFAY >>> >>> Red Hat Česká republika <https://www.redhat.com/> >>> >>> Purkyňova 115 >>> <https://maps.google.com/?q=%C4%8Cesk%C3%A1+republika+Purky%C5%88ova+115&a... >>> TPB-B 612 00 Brno >>> >>> M: +421948286055 >>> <https://red.ht/sig> >>> >> >> > > > -- > > PAVOL LOFFAY > > Red Hat Česká republika <https://www.redhat.com/> > > Purkyňova 115 TPB-B 612 00 Brno > > M: +421948286055 > <https://red.ht/sig> > -- PAVOL LOFFAY Red Hat Česká republika <https://www.redhat.com/> Purkyňova 115 TPB-B 612 00 Brno M: +421948286055 <https://red.ht/sig>

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(a)redhat.com&gt; 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-cl > ient/src/main/java/org/jboss/resteasy/client/jaxrs/Resteasy > ClientBuilder.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(a)redhat.com&gt; 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(a)redhat.com&gt; >> 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(a)redhat.com&gt; >>> 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(a)redhat.com&gt; >>>> 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. >>>>> >>>>> [1] https://issues.jboss.org/browse/SWARM-1691 >>>>> >>>>> >>>>> -- >>>>> >>>>> PAVOL LOFFAY >>>>> >>>>> Red Hat Česká republika <https://www.redhat.com/> >>>>> >>>>> Purkyňova 115 >>>>> <https://maps.google.com/?q=%C4%8Cesk%C3%A1+republika+Purky%C5%88ova+115&a... >>>>> TPB-B 612 00 Brno >>>>> >>>>> M: +421948286055 >>>>> <https://red.ht/sig> >>>>> >>>> >>>> >>> >>> >>> -- >>> >>> PAVOL LOFFAY >>> >>> Red Hat Česká republika <https://www.redhat.com/> >>> >>> Purkyňova 115 >>> <https://maps.google.com/?q=%C4%8Cesk%C3%A1+republika+Purky%C5%88ova+115+%... >>> TPB-B 612 00 Brno >>> >>> M: +421948286055 >>> <https://red.ht/sig> >>> >> >> >> >> -- >> >> PAVOL LOFFAY >> >> Red Hat Česká republika <https://www.redhat.com/> >> >> Purkyňova 115 >> <https://maps.google.com/?q=%C4%8Cesk%C3%A1+republika+Purky%C5%88ova+115&a... >> TPB-B 612 00 Brno >> >> M: +421948286055 >> <https://red.ht/sig> >> > > > > -- > > PAVOL LOFFAY > > Red Hat Česká republika <https://www.redhat.com/> > > Purkyňova 115 > <https://maps.google.com/?q=%C4%8Cesk%C3%A1+republika+Purky%C5%88ova+115&a... > TPB-B 612 00 Brno > > M: +421948286055 > <https://red.ht/sig> >