Re: Providers ordering


Sergey Beryozkin
 

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



--


Join jaxrs-spec@javaee.groups.io to automatically receive all group messages.