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

By an annotation you mean something like @PreferBuiltinProviders? I don’t see how that addresses the requirements outlined in JIRA 537. — Santiago

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

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

Hi Pavel 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

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

Hi Sergey, please see inline. 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

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

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

Hi, Time is quickly running out, and I guess what the plans are regarding CDI alignment. There's an open issue [1] labeled as "2.1-candidate" but it seems no work has been done on that yet. Given the

Hi, I too would greatly love to see this happening. CDI alignment IMHO should have been -the- major theme of Java EE and unfortunately too few steps have been made towards that goal. Kind

Yeah, I think that makes sense. So maybe instead of new methods on the Client/ClientBuilder we could add the following properties to Client: public static final String PROXY_HOST_PROPERTY =

Hi Andy, Dennis, proxy port and proxy host can be already be defined by java property (http.proxyHost and http.proxyPort). I'm not sure whether we can add proxy auth schemes at this

Hi Pavel, The java properties will specify proxy host/port for the entire JVM. Some of my customers are using JAX-RS clients in hybrid cloud environments where they may need a proxy server to

Hi Andy, Pavel Would it make sense to consider extending the security related part of the API a bit ? It already has some methods for setting up HTTPS the portable way.

Hi Sergey, Andy, Dennis, all, it would definitely make sense, but there are always issues when you need to provide credentials. Since JAX-RS client is generally an object, which should

> Note that Accept-Language is a list of languages, not a single one Ah, that's a good point, I wasn't aware of that. My feeling is that JAX-RS should select the right Locale (however that would look

selecting a right locale might be problematic. Imagine you have two resource method, one serving orders and the other one items. Items can be returned in different set of languages than orders.

Hi Pavel While it is indeed the case there are many authentication options against the target, I wonder how many options are there when we are talking about the HTTP proxies ?