Date   

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)

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



Re: Providers ordering

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




Re: Providers ordering

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


Re: Providers ordering

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



Re: Providers ordering

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


Re: Providers ordering

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


Re: #544: Localization & BeanValidation

Sergey Beryozkin
 

Can those providers which need it, ex, BV exception mappers, depend on the existing injectable Configuration interface to ensure the locales or other info can be accessed in a portable way ?

Cheers, Sergey


Re: #544: Localization & BeanValidation

Pavel Bucek
 

We are still not exactly sure how / whether it should be put into place.

JAX-RS implementation has to have list of supported locales, because there is a defined algorithm, which chooses effective locale for the response. Note that Accept-Language is a list of languages, not a single one. Thus we'd need to somehow get a list of supported languages and invoke algorithm which computes effective language/Locale for the response entity.

If there would be BV API which could do that, it would be great (I mean - if there would be a way how to pass a list of possible locales and let BV runtime to do the rest).

Introducing new interface like SupportedLocaleProvider is viable option, but when I try to get into a "user role", I would expect something more from that - maybe adding Language header to the response. That is certainly possible, but again problematic, since there is no guarantee that the response entity will respect that (and JAX-RS would need to provide a way how to obtain computed Language).

Also, seems like one of the main motivations for doing this is to provide support for MVC - and if there is Provider priority, this could be handled on MVC side (including BV, if MVC chooses to use it)..

Regards,
Pavel


On 25/05/2017 08:56, Markus KARG wrote:

If we want to support I18N on the JAX-RS server, it only would be straightforward to not only translation BV messages, but we also have to provide similar services to ALL providers, too. For example, why should it be correct that BV is supported, but custom exception providers are not, also custom MBWs (like for PDF) are not? I mean, content is content, and a service should be available to ALL sources of content, not just to BV.

 

From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Gunnar Morling via Groups.Io
Sent: Mittwoch, 24. Mai 2017 17:54
To: jaxrs-spec@javaee.groups.io
Subject: Re: [jaxrs] #544: Localization & BeanValidation

 

Bean Validation spec lead here, thanks a lot for considering this feature!

> Since there is no way how to get a list of supported locales

Why is it that you need to get the list of locales? The Locale mechanism has fallback implemented which is used by Bean Validation. So e.g. say you have ValidationMessages.properties, ValidationMessages_en.properties and ValidationMessages_de.properties. If you request with "en" or "en_US", it'd take the second. If you request with "de", it'd take the last one. If you request with any other Locale, it'd take the first one. This all happens automatically.

> hence the CLIENT programmer (like MVC API, JSF, JavaFX) just as HE has to find nice and translated phrases for ANY OTHER exception already

I think there are good reasons for doing I18N on the server and on the client, it's not that one is always better than the other. E.g. doing it on the backend (i.e. JAX-RS) allows different clients to benefit from translations (say a JavaFX client as well as a web client using the same REST API). JSF btw. is integrating with Bean Validation already in the suggested way: it takes its current Locale and passes it to BV. I personally think JAX-RS could do it exactly in the same way: set up a Bean Validation message interpolator which takes the Locale from requests and passes this to calls of interpolate().

--Gunnar



Re: #544: Localization & BeanValidation

 

If we want to support I18N on the JAX-RS server, it only would be straightforward to not only translation BV messages, but we also have to provide similar services to ALL providers, too. For example, why should it be correct that BV is supported, but custom exception providers are not, also custom MBWs (like for PDF) are not? I mean, content is content, and a service should be available to ALL sources of content, not just to BV.

 

From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Gunnar Morling via Groups.Io
Sent: Mittwoch, 24. Mai 2017 17:54
To: jaxrs-spec@javaee.groups.io
Subject: Re: [jaxrs] #544: Localization & BeanValidation

 

Bean Validation spec lead here, thanks a lot for considering this feature!

> Since there is no way how to get a list of supported locales

Why is it that you need to get the list of locales? The Locale mechanism has fallback implemented which is used by Bean Validation. So e.g. say you have ValidationMessages.properties, ValidationMessages_en.properties and ValidationMessages_de.properties. If you request with "en" or "en_US", it'd take the second. If you request with "de", it'd take the last one. If you request with any other Locale, it'd take the first one. This all happens automatically.

> hence the CLIENT programmer (like MVC API, JSF, JavaFX) just as HE has to find nice and translated phrases for ANY OTHER exception already

I think there are good reasons for doing I18N on the server and on the client, it's not that one is always better than the other. E.g. doing it on the backend (i.e. JAX-RS) allows different clients to benefit from translations (say a JavaFX client as well as a web client using the same REST API). JSF btw. is integrating with Bean Validation already in the suggested way: it takes its current Locale and passes it to BV. I personally think JAX-RS could do it exactly in the same way: set up a Bean Validation message interpolator which takes the Locale from requests and passes this to calls of interpolate().

--Gunnar


Re: Providers ordering

 

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.


Re: Providers ordering

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.



Re: #544: Localization & BeanValidation

Santiago Pericas-Geertsen
 

Hi Gunnar,

 Other than message interpolation, is there any other scenario where locale information is important in BV? What comes to mind is a string that contains a representation of a locale-specific date format, for example. 

 Pavel and I were discussing locale support included but not limited to message interpolation. I think you’re right about the fallback for messages.

— Santiago

On May 24, 2017, at 11:54 AM, Gunnar Morling via Groups.Io <gunnar.morling@...> wrote:

Bean Validation spec lead here, thanks a lot for considering this feature!

> Since there is no way how to get a list of supported locales

Why is it that you need to get the list of locales? The Locale mechanism has fallback implemented which is used by Bean Validation. So e.g. say you have ValidationMessages.properties, ValidationMessages_en.properties and ValidationMessages_de.properties. If you request with "en" or "en_US", it'd take the second. If you request with "de", it'd take the last one. If you request with any other Locale, it'd take the first one. This all happens automatically.

> hence the CLIENT programmer (like MVC API, JSF, JavaFX) just as HE has to find nice and translated phrases for ANY OTHER exception already

I think there are good reasons for doing I18N on the server and on the client, it's not that one is always better than the other. E.g. doing it on the backend (i.e. JAX-RS) allows different clients to benefit from translations (say a JavaFX client as well as a web client using the same REST API). JSF btw. is integrating with Bean Validation already in the suggested way: it takes its current Locale and passes it to BV. I personally think JAX-RS could do it exactly in the same way: set up a Bean Validation message interpolator which takes the Locale from requests and passes this to calls of interpolate().

--Gunnar


Re: #544: Localization & BeanValidation

Gunnar Morling
 

Bean Validation spec lead here, thanks a lot for considering this feature!

> Since there is no way how to get a list of supported locales

Why is it that you need to get the list of locales? The Locale mechanism has fallback implemented which is used by Bean Validation. So e.g. say you have ValidationMessages.properties, ValidationMessages_en.properties and ValidationMessages_de.properties. If you request with "en" or "en_US", it'd take the second. If you request with "de", it'd take the last one. If you request with any other Locale, it'd take the first one. This all happens automatically.

> hence the CLIENT programmer (like MVC API, JSF, JavaFX) just as HE has to find nice and translated phrases for ANY OTHER exception already

I think there are good reasons for doing I18N on the server and on the client, it's not that one is always better than the other. E.g. doing it on the backend (i.e. JAX-RS) allows different clients to benefit from translations (say a JavaFX client as well as a web client using the same REST API). JSF btw. is integrating with Bean Validation already in the suggested way: it takes its current Locale and passes it to BV. I personally think JAX-RS could do it exactly in the same way: set up a Bean Validation message interpolator which takes the Locale from requests and passes this to calls of interpolate().

--Gunnar


Re: Returning CompletionStage from the resource method

 

Won't that work what I proposed in the issue tracker:

Giving it a second thought I wonder whether Servlet's AsyncContext wouldn't provide what I proposed originally: A handle to the "original" executor (not in the sense of Executor class, but in the sense of separation of concerns).

The servlet could invoke JAX-RS using request.startAsync().start(r), where r first invokes JAX-RS, gets the resulting CompletionStage, and adds to that whenComplete((o,e) ->

{...; asyncContext.complete()}

);

I assume that AsyncContext.complete() will in turn send the HttpServletResponse using the Servlet's own thread pool.


Re: Providers ordering

 

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.


Re: #544: Localization & BeanValidation

 

A JAX-RS application produces machine-readable information (XML, JSON, etc.), hence it does not support ANY human language by definition. BV provides machine-readable ConstraintViolations for this purpose; the message text plays no role in "real" REST, just like any message text of any Exception is of no interest to the end user. In a RESTful scenario, the translation of the BV exception is up to the front end designer, hence the CLIENT programmer (like MVC API, JSF, JavaFX) just as HE has to find nice and translated phrases for ANY OTHER exception already: Exceptions are INTERNAL and not to be forwarded 1:1 to the end user! So it is up to HIM to define the languages, while the text contained in a server's "error page" should stay in the same language always as it is NOT intended for the end user but for the programmer / administrator / devop! Hence how shall the author of a JAX-RS application ever decide which languages to support? JAX-RS does NOTHING with this information as you already said! In addition, what happens if the application programmer declares to define Chinese, but the BV implementation does not support Chinese? That won't work. I would rather say, this is solely a MVC feature and should not be defined by JAX-RS.


Re: ClientBuilder#executorService

 

Sounds good. On the other hand, we simply could say that a Java EE 8 Full Product MUST use the Managed Executor Service, other Java EE 8 Non-Full-Product Profiles SHOULD use the Managed Executor Service but MUST fallback to the Java SE 8 case if not supported.


Re: #544: Localization & BeanValidation

Sergey Beryozkin
 

Hi Pavel

Where would usually the code wishing to pass the Locale get the list of supported locales from, without even getting JAX-RS involved ?

If there was some well-known mechanism then the JAX-RS runtime would just use it as opposed to having to deal with a new provider...

Cheers, Sergey

On 22/05/17 17:46, Pavel Bucek wrote:

Dear experts,

we are working on improving integration with BeanValidation [1], and seems like if we choose to address this issue, the change will be slightly bigger than I anticipated.

In short, the issue is about providing Locale based on incoming request to the BV runtime, which can then choose it to provide localized error message. Since there is no way how to get a list of supported locales, we'd need to introduce a provider, which would register supported locales:

public interface SupportedLocaleProvider {
    
    List<Locale> getSupportedLocales();
}

If the application contains @Provider annotated subclass of this interface and there is a BV message to be produced, implementation would be required to do something like:

SupportedLocaleProvider supportedLocaleProvider = ...;
javax.ws.rs.Request request = ...;

List<Locale> locales = supportedLocaleProvider.getSupportedLocales();

javax.ws.rs.Variant.VariantListBuilder variantListBuilder = Variant.VariantListBuilder.newInstance();

List<Variant> vs = variantListBuilder.languages(locales.toArray(new Locale[]{})).build();
Variant v = request.selectVariant(vs);

(+ null checks, etc). If selected variant exists, then "v.getLanguage()" would be used as a Locale passed to BV runtime.

Please let us know what do you think about proposed solution of linked issue.

Also, the introduced interface might have more uses that just this (maybe too specific) case - any brainstorming ideas to what it could be used are welcomed.

Thanks and regards, Pavel

[1] https://github.com/jax-rs/api/issues/544



#544: Localization & BeanValidation

Pavel Bucek
 

Dear experts,

we are working on improving integration with BeanValidation [1], and seems like if we choose to address this issue, the change will be slightly bigger than I anticipated.

In short, the issue is about providing Locale based on incoming request to the BV runtime, which can then choose it to provide localized error message. Since there is no way how to get a list of supported locales, we'd need to introduce a provider, which would register supported locales:

public interface SupportedLocaleProvider {
    
    List<Locale> getSupportedLocales();
}

If the application contains @Provider annotated subclass of this interface and there is a BV message to be produced, implementation would be required to do something like:

SupportedLocaleProvider supportedLocaleProvider = ...;
javax.ws.rs.Request request = ...;

List<Locale> locales = supportedLocaleProvider.getSupportedLocales();

javax.ws.rs.Variant.VariantListBuilder variantListBuilder = Variant.VariantListBuilder.newInstance();

List<Variant> vs = variantListBuilder.languages(locales.toArray(new Locale[]{})).build();
Variant v = request.selectVariant(vs);

(+ null checks, etc). If selected variant exists, then "v.getLanguage()" would be used as a Locale passed to BV runtime.

Please let us know what do you think about proposed solution of linked issue.

Also, the introduced interface might have more uses that just this (maybe too specific) case - any brainstorming ideas to what it could be used are welcomed.

Thanks and regards, Pavel

[1] https://github.com/jax-rs/api/issues/544


Re: Providers ordering

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




--