Date   

JCP web page

Alessio Soldano
 

The https://jcp.org/en/jsr/detail?id=370 page has to be updated with proper links to discussion mailing lists, archives etc; can the EG lead please do that?



Re: JCP web page

Pavel Bucek
 

Hi Alessio,

the migration is still in progress, please be patient.

We don't have email archives ready (yet), the issues have been migrated to https://github.com/jax-rs/api/issues (as already stated). I'm currently not sure how/whether the webpage and wikis from java.net will be available, we'll keep you updated.

Sorry for any inconvenience.

Best regards,
Pavel


On 16/05/2017 12:01, asoldano@... wrote:

The https://jcp.org/en/jsr/detail?id=370 page has to be updated with proper links to discussion mailing lists, archives etc; can the EG lead please do that?




Re: [jax-rs-spec users] RxInvokerProvider

Santiago Pericas-Geertsen
 

Hi Jim,

 We’ll have to wait until the e-mail migration is completed to look at the original thread.

On May 16, 2017, at 12:06 AM, Jim Ma <mail2jimma@...> wrote:

Hi Santiago, 
Before java.net is closed and all the archive emails are lost, I didn't finish going through all the traffic and find the archive email about this jave generic issue?  Can you please explain it again ?  
Does user creates provider and
instantiate invoker like following still have this generic issue ?
 
   public class CompletionStageRxInvokerProvider implements RxInvokerProvider<AnotherCompletionStageRxInvokerImpl> {
      public AnotherCompletionStageRxInvokerImpl getRxInvoker(SyncInvoker syncInvoker, ExecutorService executorService) {
          return new AnotherCompletionStageRxInvokerImpl(syncInvoker, executorService);
      }
   }

AnotherCompletionStageRxInvokerImpl invoker = builder.rx(new CompletionStageRxInvokerProvider())

 I can’t recall if this particular pattern was explored. Generally, however, a provider in JAX-RS is a type that is registered and not instantiated by application code. In fact, the default scope for providers is application scope. So the general idea is to instantiate it once and then use it many times to obtain whatever it provides (RxInvoker instances in this case). 

— Santiago


On Tue, May 9, 2017 at 9:19 PM, Santiago Pericas-Geertsen <santiago.pericasgeertsen@...> wrote:
Hi Jim,

 Once we introduced the notion of a provider to instantiate invokers, we run into a Java generics issue that we could not resolve (you can check the archives here [1]). The current solution was a bit of a compromise between requirements and type system capabilities.

— Santiago


On May 8, 2017, at 11:59 PM, Jim Ma <mail2jimma@...> wrote:

Hi, 
The new added RxInvokerProvider must be registered to the client using Client.register(Class) before create another reactive implementation invoker. Why do we need register to client first? Is it good that we simply change the Invocation.Builde#rx to 
   public <T extends RxInvoker> T rx(RxInvokerProvider<T> provider)
   {
      return provider.getRxInvoker(this, executorService);
   }
without register ? 

Thanks,
Jim




ClientBuilder#executorService

Pavel Bucek
 

Dear experts,

please let me know if you find anything wrong with following statements:

on Java EE container:

- JAX-RS client will use ManagedExecutorService for async/reactive calls unless set explicitly by ClientBuilder#executorService

on Java SE:

- JAX-RS client will use undefined, implementation specific ExecutorService for async/reactive call, unless set explicitly by ClientBuilder#executorService

Thanks,
Pavel


Re: ClientBuilder#executorService

Guillermo González de Agüero
 

Hi,

Perhaps this is a naive question, but how is the "managed" executor service handled on the Web Profile? Does "managed" mean that it must use a JSR 236 executor, or does it just refer to any "container managed" one?

The Web Profile does not include JSR 236, hence my question.


Regards,

Guillermo González de Agüero

El jue., 18 de mayo de 2017 17:37, Pavel Bucek <pavel.bucek@...> escribió:
Dear experts,

please let me know if you find anything wrong with following statements:

on Java EE container:

     - JAX-RS client will use ManagedExecutorService for async/reactive
calls unless set explicitly by ClientBuilder#executorService

on Java SE:

     - JAX-RS client will use undefined, implementation specific
ExecutorService for async/reactive call, unless set explicitly by
ClientBuilder#executorService

Thanks,
Pavel





Re: ClientBuilder#executorService

Pavel Bucek
 

Hello,

good question, thanks.

Managed executor service references JSR 236 and I'd expect that when not present, the jndi lookup described in the spec would return null and jax-rs implementation will then fallback to "java se" case.

Thanks for pointing that out, I guess we'd need to rephrase the condition to something like "When JSR 236 is available, provided managed executor service has to be used as an executor service for asynchronous client calls."

Regards,
Pavel


On 18/05/2017 18:49, Guillermo González de Agüero wrote:
Hi,

Perhaps this is a naive question, but how is the "managed" executor service handled on the Web Profile? Does "managed" mean that it must use a JSR 236 executor, or does it just refer to any "container managed" one?

The Web Profile does not include JSR 236, hence my question.


Regards,

Guillermo González de Agüero

El jue., 18 de mayo de 2017 17:37, Pavel Bucek <pavel.bucek@...> escribió:
Dear experts,

please let me know if you find anything wrong with following statements:

on Java EE container:

     - JAX-RS client will use ManagedExecutorService for async/reactive
calls unless set explicitly by ClientBuilder#executorService

on Java SE:

     - JAX-RS client will use undefined, implementation specific
ExecutorService for async/reactive call, unless set explicitly by
ClientBuilder#executorService

Thanks,
Pavel






Providers ordering

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


Returning CompletionStage from the resource method

Pavel Bucek
 

Dear experts,

as we already stated, we'd like to support returning CompletionStage from the resource mehod, corresponding spec issue is here:

https://github.com/jax-rs/api/issues/551

The only open issue is related to the thread on which the response will be processed (on which will be the "whenComplete" callback invoked").

Markus suggests that it could/should be done on servlet provided thread/executor, but there is no facility which would give as such thread. The case mentioned in the issue comment won't work, because "whenComplete" would be invoked on the thread which completed the CompletionStage (i.e.: there is no magic which would get back the thread, which was already handled over back to the servlet container). We could leave it like that (the application would need to have some thread which will complete the stage anyway) or we can say that container managed thread will be used, if available.

Please let us know if you have any suggestions or comments.

Thanks and regards,
Pavel


Re: Providers ordering

Guillermo González de Agüero
 

Hi,

Have you considered how this will behave when the provider is a CDI @Alternative or @Stereotype?

I'm unsure how much those could interfere but I think it's something to take into account nonetheless, specially since improved CDI integration is already planned [1].


Regards,

Guillermo González de Agüero



El vie., 19 de mayo de 2017 14:04, Pavel Bucek <pavel.bucek@...> escribió:

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


Built-in proxy support in Client API?

Andy McCright
 

Hi all,
 
It might be too late to add this (if so, no worries), but I've been running into a few customer situations where customers are using HTTP/HTTPS proxy servers with their JAX-RS client APIs.  Today, proxy support is enabled, but requires vendor-specific properties.  Would it make sense to add some methods to ClientBuilder/Client/Configurable like proxyHost(String), proxyPort(int), proxyBasicAuth(String user, byte[] password), etc.?
 
Here is a relevant issue where this was previously discussed: https://github.com/jax-rs/api/issues/497
 
Thanks,
 
Andy
 


J. Andrew McCright
IBM WebSphere Development
+1 507 253 7448
TL 553-7448
andymc@...


Re: Providers ordering

 

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





Re: Providers ordering

Pavel Bucek
 

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




--


Re: Providers ordering

Guillermo González de Agüero
 

Hi,

On Sun, May 21, 2017 at 11: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.

I was writing to propose exactly that. That's be the more flexible approach, and would resolve my open question about what exactly is a built-in provider (https://github.com/jax-rs/api/issues/537#issuecomment-302853229).


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




--



Regards,

Guillermo González de Agüero.


Re: Built-in proxy support in Client API?

Dennis Kieselhorst
 

Hi,

in my view there should be at least standardized constants for the properties in 2.1. I created a PR for the timeout stuff yesterday: https://github.com/jax-rs/api/pull/555

These properties can be used by convenience methods in ClientBuilder.

I can also create a PR for the proxy constants if the solution is agreed.

Regards

Dennis


Re: Providers ordering

 

Hey Pavel,

thanks a lot for your quick reply.

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.

Thanks a lot for pointing me to section 4.2.4. But as you already wrote the current version of this statement just covers entity providers.
 

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.

I would be fine with both options as both would fix the problem I mentioned. Although I think the latter one would should be preferred because it is much simpler.


Best regards

Christian


--


Re: Providers ordering

Sergey Beryozkin
 

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.

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 ?

Thanks Sergey

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




--



Re: Returning CompletionStage from the resource method

Sergey Beryozkin
 

Hi Pavel

I'd leave it up to the implementation to decide.

The other thing I was thinking about. On the client side we have RxInvoker which supports not only CompletableFuture. Should we have something like RxResponse such that not only CompletableFuture is supported ?

Thanks, Sergey




Re: Providers ordering

 

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



--


Re: Providers ordering

Sergey Beryozkin
 

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



--



Re: Providers ordering

 

Hey Sergey,

thanks for your quick reply.


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.

 
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



--