Fwd: SPI to add JAX-RS annotations dynamically
by Alessio Soldano
Forwarding to the list :-)
---------- Forwarded message ----------
From: Alessio Soldano <asoldano(a)redhat.com>
Date: Wed, Sep 27, 2017 at 10:24 PM
Subject: Re: [resteasy-dev] SPI to add JAX-RS annotations dynamically
To: Christian Kaltepoth <christian(a)kaltepoth.de>
Hi Christian,
On Wed, Sep 27, 2017 at 9:19 PM, Christian Kaltepoth <christian(a)kaltepoth.de
> wrote:
>
> sorry for the delayed response. I agree that if some SPI would allow to
> modify the builders, it should be done before the resource is registered in
> the resource factory. Do you think such a SPI would be useful for others?
>
Probably yes, but your scenario might even be enough to justify it.
I would be happy to contribute some code if it improves portability between
> RESTEasy and the MVC RI.
>
Sure, feel free to work on that and send a PR.
> Thanks for pointing me to the resteasy-cdi integration. I'll have a deeper
> look at it in the next days.
>
OK, good, I hope that can offer some idea for integrating.
Cheers
Alessio
6 years, 1 month
Microprofile OpenTracing integration for WF Swarm
by Pavol Loffay
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 TPB-B 612 00 Brno
M: +421948286055
<https://red.ht/sig>
6 years, 5 months
Re: [resteasy-dev] resteasy jax-rs fail fast on entity validation exception
by Alessio Soldano
Hi John,
sorry, I'm a bit busy atm, anyway I'm forwarding your email to the
resteasy-dev list. We'll get back to you.
Cheers
Alessio
On Tue, Oct 24, 2017 at 11:59 AM, John O'Hara <johara(a)redhat.com> wrote:
> Alessio,
>
> I am not sure if you are the correct person to ask, if not please let me
> if there is someone more appropriate to ask.
>
> I have been investigating some unexpected behaviour in how entity
> validations exceptions are propagated through WF/EAP when http post
> requests are made via rest endpoints.
>
> One thing I have noticed in the resteasy-jaxrs module is that
> in org.jboss.resteasy.core.MethodInjectorImpl.invoke() the method
> parameters are validated [1], but the method is still invoked, irrespective
> of the outcome of the call to the validator [2]
>
> Is there is a possibility of failing a method invocation after the
> validation call [1], so that we do not invoke the method, which ends up
> failing anyway due to validation exceptions?
>
> Thanks
>
> John
>
> [1] https://github.com/resteasy/Resteasy/blob/master/
> resteasy-jaxrs/src/main/java/org/jboss/resteasy/core/
> MethodInjectorImpl.java#L119
> [2] https://github.com/resteasy/Resteasy/blob/master/
> resteasy-jaxrs/src/main/java/org/jboss/resteasy/core/
> MethodInjectorImpl.java#L140
>
> --
>
> JOHN O'HARA
>
> PRINCIPAL SOFTWARE ENGINEER
>
> Red Hat <https://www.redhat.com/>
> <https://red.ht/sig>
> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
> @redhatway <https://twitter.com/redhatway> @redhatinc
> <https://instagram.com/redhatinc> @redhatsnaps
> <https://snapchat.com/add/redhatsnaps>
>
6 years, 6 months