Topics

Providers ordering


Pavel Bucek
 

Hi Christian.

Yes, you are right, that's a "typo".

Thanks for letting us know :)

Regards,
Pavel

On 29/05/2017 10:43, Christian Kaltepoth wrote:
Hi Pavel,

thanks a lot the explanation. I just had a look at the changes and it looks good.

One minor thing. One of the new paragraphs state:

  All application-supplied providers implement interfaces in the JAX-RS API and MAY be annotated with @Priority for automatic discovery purposes

I guess this should be @Provider, correct?



Christian


2017-05-29 10:31 GMT+02:00 Pavel Bucek <pavel.bucek@...>:

FYI:

Custom providers without @Provider annotation will have priority value javax.ws.rs.Priorities.USER (value 5000).

Also, Priority(100) > Prority(500), so provider with Priority(100) will be processed before provider with Priority(500).

More details can be found in the updated spec document, see change https://github.com/jax-rs/spec/commit/817c16fdf8cd8528041b7597bc19f4f7e010ec88 .

Regards,
Pavel


On 25/05/2017 16: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 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.

Since I believe we have working proposal (backed up by the implementation), 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.

Thanks and regards,
Pavel


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





--


 

Hi Pavel,

thanks a lot the explanation. I just had a look at the changes and it looks good.

One minor thing. One of the new paragraphs state:

  All application-supplied providers implement interfaces in the JAX-RS API and MAY be annotated with @Priority for automatic discovery purposes

I guess this should be @Provider, correct?



Christian


2017-05-29 10:31 GMT+02:00 Pavel Bucek <pavel.bucek@...>:

FYI:

Custom providers without @Provider annotation will have priority value javax.ws.rs.Priorities.USER (value 5000).

Also, Priority(100) > Prority(500), so provider with Priority(100) will be processed before provider with Priority(500).

More details can be found in the updated spec document, see change https://github.com/jax-rs/spec/commit/817c16fdf8cd8528041b7597bc19f4f7e010ec88 .

Regards,
Pavel


On 25/05/2017 16: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 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.

Since I believe we have working proposal (backed up by the implementation), 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.

Thanks and regards,
Pavel


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






Pavel Bucek
 

FYI:

Custom providers without @Provider annotation will have priority value javax.ws.rs.Priorities.USER (value 5000).

Also, Priority(100) > Prority(500), so provider with Priority(100) will be processed before provider with Priority(500).

More details can be found in the updated spec document, see change https://github.com/jax-rs/spec/commit/817c16fdf8cd8528041b7597bc19f4f7e010ec88 .

Regards,
Pavel


On 25/05/2017 16: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 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.

Since I believe we have working proposal (backed up by the implementation), 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.

Thanks and regards,
Pavel


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



 

By annotation I mean something like "@UseThisProviderOnlyIfNonIsBuiltIn" attached to an application-provided provider (certainly with a smarter name).

 

It is unrelated to any JIRA issue. I just came into my mind as we had this requirement several times in the past, which always ended up the same: The application provided a fallback provider (just to be sure there will be one), so the potential built-in one always was skipped -- rendering the built-in useless.

 

This annotation is needed whenever an application wants to trust a particular feature to be provided, but the JAX-RS specification does not mandate this feature. Thinks of support for OAuth for example, which is optional currently, but may be mandatory in future. Applications could provide own OAuth now and markt it as "fall-back-only". Or JSON-B. etc.

 

-Markus

 

From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Santiago Pericas-Geertsen
Sent: Donnerstag, 25. Mai 2017 16:02
To: jaxrs-spec@javaee.groups.io
Subject: Re: [jaxrs] Providers ordering

 

 

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

 


Sergey Beryozkin
 

Hi Pavel

Thanks, sorry, your note re having a working implementation was not of the most major concern :-), I was only trying to imply that
well, sometimes we have to be ready to adjust our code, though I know RI has a good code :-).
Either way, as far as I'm concerned, I reckon we can probably won't have a better alternative to using @Priority

Thanks, Sergey

On 25/05/17 16:19, Pavel Bucek wrote:

Hi Sergey,

please see inline.


On 25/05/2017 17:04, Sergey Beryozkin wrote:
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.
yes, exactly.

I was trying to offer another point of view on that issue, seemed like you are suggesting that the proposal uses @Priority in a way that contradicts its purpose.


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 ?

I'm sorry if that statement felt like something too offensive.

All I wanted to say there was "hey, this proposal does work, we know it, since we do have backing implementation. with tests. :)"

I could use the argument that says "we need to have RI implementation for anything we do propose here, because if we don't, the feature cannot be part of the spec", since we have to have everything ready for PFD, but .. it is not the case here.

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)

I do see it as "contextual" priority and the context is defined by the provider definition. I don't have any examples from Java EE in mind right now, but sorting something (by the priority) and then picking "the best" provider seems to be natural. Also, if a provider is a filter and filter contract defines that all filters have to be executed, then using @Priority for sorting them doesn't feel wrong. I do agree that there is a difference, but the difference is in providers declaration, not in the semantics of @Priority.

Of course, I can be wrong ;) Please let me know what do you think.

Best regards,
Pavel


Sergey


Thanks and regards,
Pavel


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





Pavel Bucek
 

Hi Sergey,

please see inline.


On 25/05/2017 17:04, Sergey Beryozkin wrote:
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.
yes, exactly.

I was trying to offer another point of view on that issue, seemed like you are suggesting that the proposal uses @Priority in a way that contradicts its purpose.


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 ?

I'm sorry if that statement felt like something too offensive.

All I wanted to say there was "hey, this proposal does work, we know it, since we do have backing implementation. with tests. :)"

I could use the argument that says "we need to have RI implementation for anything we do propose here, because if we don't, the feature cannot be part of the spec", since we have to have everything ready for PFD, but .. it is not the case here.

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)

I do see it as "contextual" priority and the context is defined by the provider definition. I don't have any examples from Java EE in mind right now, but sorting something (by the priority) and then picking "the best" provider seems to be natural. Also, if a provider is a filter and filter contract defines that all filters have to be executed, then using @Priority for sorting them doesn't feel wrong. I do agree that there is a difference, but the difference is in providers declaration, not in the semantics of @Priority.

Of course, I can be wrong ;) Please let me know what do you think.

Best regards,
Pavel


Sergey


Thanks and regards,
Pavel


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




Sergey Beryozkin
 

Hi Santiago
On 25/05/17 15:59, Santiago Pericas-Geertsen wrote:

On May 25, 2017, at 10:40 AM, Sergey Beryozkin <sberyozkin@...> wrote:

Hi Santiago

In what other cases, apart from ensuring a mapper shipped with MVC (or other spec APIs depending on JAX-RS), we would want to support sorting two ExceptionMapper<SomeClass> ?

 That is the main use case AFICT. Any library/framework sitting on top of JAX-RS may need finer control over this. @Priority is already used for filters and interceptors, except that in this case the entire set is consider rather than just one —but there is precedence of using this annotation nonetheless.

 Conceptually, this is what I have in mind, for all providers:

 1. Gather list of candidates
 2. Filter list based on provider-specific predicate
 3. Sort resulting list based on priority
 4. Pick one or all depending on provider kind

4. states it well, I agree in the end of the day this is probably the most pragmatic solution

Cheers, Sergey

— Santiago


Cheers, Sergey
 
On 25/05/17 15:01, Santiago Pericas-Geertsen wrote:

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





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)

Sergey


Thanks and regards,
Pavel


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



Santiago Pericas-Geertsen
 


On May 25, 2017, at 10:40 AM, Sergey Beryozkin <sberyozkin@...> wrote:

Hi Santiago

In what other cases, apart from ensuring a mapper shipped with MVC (or other spec APIs depending on JAX-RS), we would want to support sorting two ExceptionMapper<SomeClass> ?

 That is the main use case AFICT. Any library/framework sitting on top of JAX-RS may need finer control over this. @Priority is already used for filters and interceptors, except that in this case the entire set is consider rather than just one —but there is precedence of using this annotation nonetheless.

 Conceptually, this is what I have in mind, for all providers:

 1. Gather list of candidates
 2. Filter list based on provider-specific predicate
 3. Sort resulting list based on priority
 4. Pick one or all depending on provider kind

— Santiago


Cheers, Sergey
 
On 25/05/17 15:01, Santiago Pericas-Geertsen wrote:

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




Pavel Bucek
 

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 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.

Since I believe we have working proposal (backed up by the implementation), 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.

Thanks and regards,
Pavel


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


Sergey Beryozkin
 

Hi Santiago

In what other cases, apart from ensuring a mapper shipped with MVC (or other spec APIs depending on JAX-RS), we would want to support sorting two ExceptionMapper<SomeClass> ?

Cheers, Sergey
 

On 25/05/17 15:01, Santiago Pericas-Geertsen wrote:

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



Santiago Pericas-Geertsen
 


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


Sergey Beryozkin
 

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


 

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.


Santiago Pericas-Geertsen
 

Hi Markus,

 The precedence of application-defined vs. built-in providers has already been established and cannot be changed at this point (but should be clarified better as mentioned by others). Conceptually, we have two ordered sets and we only consider the built-in set iff the application-defined set is empty after filtering.

 In my view, the introduction of @Priority should only apply to application-defined providers —which are in fact the ones that developers can add annotations to.

— Santiago
 

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.



 

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.


Santiago Pericas-Geertsen
 


On May 21, 2017, at 7:42 AM, Sergey Beryozkin <sberyozkin@...> wrote:

Hi Pavel

Not sure it is relevant but it is not exactly the case with MessageBodyReader/Writers where the custom providers can still lose to built-in providers.

 Priority should only be used to break ties. Certain providers have well-defined selection algorithms, but in some cases the final set is not a singleton.

— Santiago

On 21/05/17 10:03, Pavel Bucek wrote:

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













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




--




Santiago Pericas-Geertsen
 


On May 21, 2017, at 5:03 AM, Pavel Bucek <pavel.bucek@...> wrote:

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?


 
 I agree. Naturally, user-defined providers should take precedence over built-in ones. Clearly, this statement is implicit rather than explicit and should be clarified —at least for some providers. That was always the intent.

 As for what is user-defined vs. built-in, I don’t thing that is hard to define: 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. 

— Santiago

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













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




--



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



--



Sergey Beryozkin
 

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...

Sergey

On 21/05/17 16:19, Sergey Beryozkin wrote:
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



--