Re: Providers ordering

Sergey Beryozkin

Hi Pavel

On 25/05/17 15:54, Pavel Bucek wrote:

Hi Sergey, others,

you suggest that the exception mapper would be part of MVC spec (not the implementation, so not in javax.* package but more like org.impl.something.*?). I think that checking package name is fragile concept and should be avoided if possible, not to mention that this setup would be not ideal for MVC implementations.

I thought that the MVC spec was shipping its own default mapper, that is way I was suggesting checking javax.*.
if it is not the case then I agree it would not work well...

I believe we shouldn't introduce new annotations whenever there is a need for a marker (which, in this case, can be easily defined without it); we already do have plenty of them..

Also, note that @Priority is not use to control what is excluded. It is used accordingly to what it is supposed to be used - to sort providers. JAX-RS implementation then needs to pick single one in most occasions and it will naturally pick more important one.
Leading to the exclusion in the end. With Filters it is obviously not the case, all of them are run.

Since I believe we have working proposal (backed up by the implementation),
IMHO that should not be used to affect the discussion given that the proposal is still under the discussion ?
let's stick to following:

- clarify what is built-in and user-defined provider using Santiagos definition:
if it is registered using the JAX-RS API or discovered via class scanning (i.e. annotated with @Provider), then it is user-defined regardless of their physical location (library, container, etc.). Built-in ones should not be made available using those mechanisms.
- define that user-defined providers will be sorted by the @Priority with respect to existing, already defined algorithms. That means it will influence which Provider is defined only when other conditions are already applied and more than one provider is equal in terms of the defined algorithm (i.e. exception type distance for ExceptionMappers).

Described change fits well in Java EE environment, since using @Provider is quite common among other specifications thus is already natural for majority of users.

Please let us know whether you have any strong objections or suggestions how to improve proposed rules.
Looks like we have no other option but to use @Priority even though it will mean @Priority is used differently when applied to exception mappers (or param converters ?). It feels wrong but I guess we don't have other options (the new annotation will do well but it is just too late for it to be introduced)


Thanks and regards,

On 25/05/2017 11:30, Sergey Beryozkin wrote:
I guess that what I also suggested when we talked with Christian about @DefaultProvider - the only problem from what I understood MVC will've been already released by the time JAX-RS 2.1 gets out.

To be honest, I'm still thinking, checking the origin (package) of the mapper can work. If for ex MVC ships its ExceptionMapper it is still a built-in mapper in context of MVC, and it can be identified to be a built-in one because it will be in a javax. namespace. Such providers should get a lower priority OOB (compared to the otherwise equal competing mappers), without having to depend on @Priority.

@Priority is there to sort the providers, making sure they execute in the right order. Using it as a mechanism to exclude does not seem quite right...Though it can work...

Cheers, Sergey

Join to automatically receive all group messages.