toggle quoted messageShow quoted text
Continuing with the idea of the special
treatment of the providers shipped with the spec implementations.
Rather than pursue a @DefaultProvider idea, how about treating the
providers in the javax.* namespace as 'default' ones ?
Thus if say an MVC API ships its own CSRF exception mapper then it
will be selected, unless the application has registered its own.
Moreover, perhaps this idea and the idea of using @Priority are
not mutually exclusive. IMHO the former puts less 'pressure' on
the application providers to make it right...
On 21/05/17 16:19, Sergey Beryozkin wrote:
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.
On 21/05/17 15:58, Christian Kaltepoth wrote: