Dear experts,

there is couple of filed issues related to provider ordering, namely:

https://github.com/jax-rs/api/issues/538
https://github.com/jax-rs/api/issues/537

We already do have them implemented in the RI and we discovered that we can do similar things for almost all providers (including readers/writers, ..), which don't have already defined @Priority handling (filters and interceptors do have that already).

For these providers, lover priority value means higher priority. For example, if you have following ExceptionMappers:

then "MySecondExceptionMapper" will be invoked when "MyException" is thrown.

@Provider
@Priority(300)
public static class MyFirstExceptionMapper implements ExceptionMapper<MyException> {
    // ...
}

@Provider
@Priority(100)
public static class MySecondExceptionMapper implements ExceptionMapper<MyException> {
    // ...

}

@Provider
@Priority(200)
public static class MyThirdExceptionMapper implements ExceptionMapper<MyException> {
    // ...

}

Do you have any comments or suggestions before we incorporate that change into the spec document?

Thanks and regards, Pavel

Hi Christian,

see chapter 4.2.4:

An implementation MUST support application-provided entity providers and MUST use those in preference to its own pre-packaged providers when either could handle the same request. More precisely, step 4 in Section 4.2.1 and step 5 in Section 4.2.2 MUST prefer application-provided over pre-packaged entity providers.

Which i s the base of what I mentioned - there is one issue though - this is only about entity providers, not about ExceptionMappers, which are covered by chapter 4.3.

I believe we could include more general statement in chapter 4, which would say that application provided Providers have priority over build-ins (and maybe define what build-in is) OR we can say that implementation providers should have some concrete priority set - which could be simpler than formally defining built-in provider.

Santiago, others, what do you think?

Thanks,
Pavel

On 21/05/2017 10:48, Christian Kaltepoth wrote:

Hi everyone,

I'm very happy to see that the issue of provider ordering is addressed in the upcoming JAX-RS release. Thanks a lot for your work on that.

I would like to point the EG to a discussion from one of the issues which was about whether the priority ordering should be used only for "custom providers" or for all providers (custom and built-in providers). See [1] for details. During the discussion Pavel mentioned that JAX-RS already mandates that custom providers are preferred over built-in providers. I didn't find this anywhere in the spec document, but maybe I just missed it.

The one thing that still makes me think that the priority ordering should be used for all providers is that the definition of "built-in provider" is a bit blurry. What is a built-in provider? What about providers which are deployed as app server modules and therefore are provided out of the box by the container? Are they built-in or custom providers? Perhaps this should simply be clarified in the spec?

I would be happy to hear about other opinions.

Christian

[1] https://github.com/jax-rs/api/issues/537#issuecomment-297653894

2017-05-19 14:08 GMT+02:00 Pavel Bucek <pavel.bucek@...>:

Dear experts,

there is couple of filed issues related to provider ordering, namely:

https://github.com/jax-rs/api/issues/538
https://github.com/jax-rs/api/issues/537

We already do have them implemented in the RI and we discovered that we can do similar things for almost all providers (including readers/writers, ..), which don't have already defined @Priority handling (filters and interceptors do have that already).

For these providers, lover priority value means higher priority. For example, if you have following ExceptionMappers:

then "MySecondExceptionMapper" will be invoked when "MyException" is thrown.

@Provider
@Priority(300)
public static class MyFirstExceptionMapper implements ExceptionMapper<MyException> {
    // ...}

@Provider
@Priority(100)
public static class MySecondExceptionMapper implements ExceptionMapper<MyException> {
    // ...

}

@Provider
@Priority(200)
public static class MyThirdExceptionMapper implements ExceptionMapper<MyException> {
    // ...

}

Do you have any comments or suggestions before we incorporate that change into the spec document?

Thanks and regards, Pavel

--

Christian Kaltepoth

Blog: http://blog.kaltepoth.de/

Twitter: http://twitter.com/chkal

GitHub: https://github.com/chkal

Hi Sergey,

By the way, what is the actual point of ordering say 2 ExceptionMapper<MyObject> - would it go a bit too far without bringing any real benefit ?

Of course nobody will want to create two ExceptionMapper<MyObject> implementations in his application. It is more about the case that some framework provides a "default" exception mapper for a specific exception type and the developer should still be able to provide a custom one which is preferred by the JAX-RS implementation.

We had this case in JSR-371 (MVC 1.0): If the validation of a CSRF token fails, the MVC implementation throws a CsrfValidationException. The MVC implementation provides a default mapper ExceptionMapper<CsrfValidationException> which just sends a 403 status code. But the developer should be able to provide a custom exception mapper which does something else, like rendering some HTML page. However, this is currently not possible, because if there are two ExceptionMapper<CsrfValidationException> implementations discovered, there is no way to tell the JAX-RS implementation which one to choose.

Christian

--

Christian Kaltepoth

Blog: http://blog.kaltepoth.de/

Twitter: http://twitter.com/chkal

GitHub: https://github.com/chkal

Hi Christian

Right, do you mean that both of these providers are custom as far as the JAX-RS implementation is concerned ?

Sure, I see what you mean now.

I guess my only doubt at this stage is, should the providers offered by MVC implementation (or some other *spec-implementaion* API) have a special treatment status, as far as JAX-RS is concerned ? Example, be annotated with some @DefaultProvider annotation (to be introduced in JAX-RS) ? In this case JAX-RS, seeing two MyObject exception mappers, will select the one which has no @DefaultProvider.

May be using @Priority is simpler, but it would require application mappers to know how to set their own @Priority to ensure it is high or low enough. The problem with @DefaultProvider is that it is probably too late as ex MVC API would need updated after 2.1 is out.

Cheers. Sergey

On 21/05/17 15:58, Christian Kaltepoth wrote:

Hi Sergey,

By the way, what is the actual point of ordering say 2 ExceptionMapper<MyObject> - would it go a bit too far without bringing any real benefit ?

Of course nobody will want to create two ExceptionMapper<MyObject> implementations in his application. It is more about the case that some framework provides a "default" exception mapper for a specific exception type and the developer should still be able to provide a custom one which is preferred by the JAX-RS implementation.

We had this case in JSR-371 (MVC 1.0): If the validation of a CSRF token fails, the MVC implementation throws a CsrfValidationException. The MVC implementation provides a default mapper ExceptionMapper<CsrfValidationException> which just sends a 403 status code. But the developer should be able to provide a custom exception mapper which does something else, like rendering some HTML page. However, this is currently not possible, because if there are two ExceptionMapper<CsrfValidationException> implementations discovered, there is no way to tell the JAX-RS implementation which one to choose.

Christian

--

Christian Kaltepoth

Blog: http://blog.kaltepoth.de/

Twitter: http://twitter.com/chkal

GitHub: https://github.com/chkal

On May 23, 2017, at 1:59 PM, Markus KARG <markus@...> wrote:

We should not mix up concerns here. @Priority should only beak tie. Whether or not to choose built-in vs. application-provided should be separately declarable. For example, in case A it might make sense that an appliation provides a simplistic fallback provider just in case the JAX-RS implementation does not provide support for a particular feature (like PDF support for example). On the other hand, the application might want to provide a superior, really-expensive, full-monty provider for PDF, which shall always override a possible existing built-in one. This example showcases that it MUST be up to the application programmer to declare precedence. But I won't use @Priority for that. It should be a separate annotation.

On May 25, 2017, at 2:41 AM, Markus KARG <markus@...> wrote:

I do not see that we cannot change this. If we decide that a new, optional annotation will modify the precedence, this would be perfectly backwards compatible, as all non-annotated code will still work correctly.

 By an annotation you mean something like @PreferBuiltinProviders? I don’t see how that addresses the requirements outlined in JIRA 537.

— Santiago