Hi Sergey, I recall getting a requests for supporting NTLM/Kerberos and maybe one other scheme - something related to ldap.. Regards, Pavel

Hey Pavel, I would like to take the opportunity to describe what MVC did to support internationalization which relates to the issue we are discussing here. As MVC builds on top of JAX-RS, this may (or

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

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

Hi Christian. Yes, you are right, that's a "typo". Thanks for letting us know :) Regards, Pavel

Hi Christian, This seems very useful, pretty much like what could be useful within JAX-RS itself. That selected Locale could then be used with a specifically set up message interpolator, just as JSF

Hi Gunnar, sorry, the term "priority" was a bit misleading in this context. Actually it uses the "quality value" from the "Accept-Language" header. See:

Dear experts, we'd like to make the HTTP PATCH support on the client optional, throwing UnsupportedOperationException on client runtimes, which don't support that method. I know that we already had

My opinion is that either we support it completely or not at all. Making it optional renders the feature useless for ISVs: If I cannot rely on it being there on _all_ platforms, I will _never_ use it,

The issue applies not only to PATCH but to all other methods which happen not be known to HttpUrlConnection. But rather than say something along the lines "only well-known verbs" can be supported and

In fact no ISV is using that optional methods unless they package their app with a particular JRE. -Markus

The issue with Sync/Async/RxInvoker#patch methods is similar to what we do have with Sync/Async/RxInvoker#method, but surprisingly #method doesn't mention anything about unsupported HTTP methods or

Hi Pavel Right, that what I was also implying, that API already allows to use any HTTP method names, so it is not only about PATCH. So we should have method(String) variations docs updated. Re

Same feeling here. Cheers Alessio

That is more-or-less my opinion too. I'd prefer that we supported the patch() method fully (not optionally), but if the decision is support it optionally or not at all, I'd choose not at all. On

I agree with Guillermo and Arjan that further CDI alignment is very important for JAX-RS. It would be great to see some EG discussion about this. Christian 2017-05-25 20:13 GMT+02:00 Arjan Tijms

Yes, agreed. Especially the ability to @Inject JAX-RS managed objects (basically what is @Context today) would be very helpful. That enables to inject UriInfo within the EE application

@Context is that little thing that has helped to make JAX-RS visible outside of the EE world, as opposed to it be yet another EE spec. Rather than trying to keep JAX-RS more and more

Hi, It's not just another EE spec, but one of the fundamental EE specs. IMHO; open as possible also means that you eventually commit to nothing and only make it more difficult and confusing to use

Hi Lest not dramatize it, difficult, confusing, all because of @Context ? I'm not going to comment. As well as re this 'ownership' claim of JAX-RS by EE.