- Weinan Li
On 11 May 2017, at 12:24 AM, Pavol Loffay <ploffay(a)redhat.com>
wrote:
On Wed, May 10, 2017 at 3:00 PM, Weinan Li <weli(a)redhat.com> wrote:
- Weinan Li
> On 10 May 2017, at 8:32 PM, Pavol Loffay <ploffay(a)redhat.com> wrote:
>
> Hello,
>
> We are working on OpenTracing jax-rs integration [1]. OpenTracing jax-rs provider
[2] can be configured with various settings (tracer instance, span decorators,
priority..), but also a default configuration with a parameterless constructor is
possible.
>
> How should be the provider implemented when we want to allow auto-discovery with a
default configuration and also a custom configuration? Currently, the problem is when
users want to use a provider with custom configuration a provider with a default
configuration is registered too.
I guess the implementation will be vendor specific. For example, you need to hack into
RESTEasy provider loading process to achieve the goal.
Implementation has to be vendor neutral like it is right now.
Let's change this to a question: Can any jax-rs implementation instantiate and
register provider based on auto-discovery and let user explicitly registers the same
provider?
The question goes back to implementation specific. CXF, Jersey and RESTEasy would be
different to answer this question. (I haven't checked CXF and Jersey sides, but it
would be possible implemented in both of this containers.)
Jax-rs spec section 2.2.2 at the bottom:
When an Application subclass is present in the archive, if both Application.getClasses
and Application.getSingletons return an empty collection then all root resource classes
and
providers packaged in the web application MUST be included and the JAX-RS implementation
is
REQUIRED to discover them automatically by scanning a .war file as described above.
If either
getClasses or getSingletons returns a non-empty collection then only those classes or
singletons
returned MUST be included in the published JAX-RS application.
It depends on the containers you are using. Wildfly(Undertow as webserver) and other
standard servlet container(such as Tomcat) should support the above behaviors.
I don't mean it's servlet container's job to support the JAX-RS spec. On the
contrary, as the spec says, the JAX-RS implementation must support the servlet container
for it to pass the TCK tests.
For other containers, there are adapters like resteasy-jdk-httpd, resteasy-netty4. Because
these are not servlet containers, and they don't rely on the Application to register
the resources
(
http://weinan.io/2017/04/10/multiple-application-support-in-jersey-and-co...)
and don't follow TCK spec (In Application scanning part).
So it should be fine, however one user reported an issue
https://github.com/opentracing-contrib/java-jaxrs/issues/25 that
MultipleServerDynamicFeatures were used.
Put it in my todo list. I'll check it.
Would love to have somebody from Reseasy team, to review and collaborate on this
occaionally.
resteasy mailing list is the right place to ask for help :-)
In addition, could you please provide a sample project to demonstrate the current use
case?
> We want only one to be registered, The default auto-discovered provider should not
be used when one is explicitly registered (with a custom configuration).
>
> We are thinking about creating a separate artifact with just one class annotated
with @Provider to be used when users want to use a default configuration with
auto-discovery. The original artifact would be used only for a custom configuration and
registration.
>
>
> [1]:
https://github.com/opentracing-contrib/java-jaxrs
> [2]:
https://github.com/opentracing-contrib/java-jaxrs/blob/master/opentracing...
>
> Regards,
>
> --
> PAVOL LOFFAY
> Red Hat Česká republika
> Purkyňova 111 TPB-B 612 45 Brno
> M: +421948286055
>
>
> _______________________________________________
> resteasy mailing list
> resteasy(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/resteasy
--
PAVOL LOFFAY
Red Hat Česká republika
Purkyňova 111 TPB-B 612 45 Brno
M: +421948286055