[resteasy-dev] Microprofile OpenTracing integration for WF Swarm

[Pavol Loffay]

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 at 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 at 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.
>>
>> [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&entry=gmail&source=g>
>> 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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/resteasy-dev/attachments/20171122/d9bed2f4/attachment.html