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
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> 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> 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>
> 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>
>> 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>