Re: Providers ordering


Sergey Beryozkin
 

Hi Christian
On 21/05/17 18:22, Christian Kaltepoth wrote:
Hey Sergey,

thanks for your quick reply.

Thanks too,

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

Yes, exactly. In this case JAX-RS currently doesn't specify which one should be used.

 
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.

Not sure if something like @DefaultProvider is flexible enough. Maybe this "default provider" vs "custom provider" use case is just one special case? I mean, it is always possible to have multiple exception mappers on the classpath if they are provided by different libraries. And in this case it would be nice to have some clear rules on how to handle this situation.
 

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.

For filters and interceptors there is already javax.ws.rs.Priorities which contains constants which can be used for ordering. So this could also be used for exception mappers and param providers.

I agree using @Priority is a viable option. But as I implied earlier, this approach (apart from solving the issue shown with MVC vs custom CSRF mapper) raises the question - why to support two ExceptionMapper<MyObject> or ParamConverters in general. Perhaps it does not really matter, but I guess we'd like to avoid supporting the solutions where the developers will start thinking about dropping 3 ExceptionMapper<MyObject>, and ordering them 1, 2, 3 and making each of them, say, 1 and 2, not to map, for 3 to do the final mapping :-).

That said, may be this example is hypothetical, and using @Priority just works, though I thought I'd suggest a 'default mapper' around javax.* idea too...  

Thanks, Sergey

 
The problem with @DefaultProvider is that it is probably too late as ex MVC API would need updated after 2.1 is out.

That wouldn't be a problem, because MVC will go final after JAX-RS and therefore could depend on JAX-RS 2.1.


Best regards

Christian



--


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