Sorry for the typo, I meant to say that "ignoring of the fact that major non-EE containers are *now* thought by"

Because this is what non EE users of JAX-RS (and there are many of them) look for (they migrate to Spring Boot and non-EE containers in general). I've always felt that this ignoring of

Technically it is. Not all nderstand though why JAX-RS is one of the most popular EE spec today - let me answer, because the developers could use it everywhere without having to ensure some EE

Why?

Yes. It's another injection and bean model and doesn't play nice with the platform wide services for things such as extensions, decorators and interceptors. This is also why we deprecated and native

Let me step back. +1 to having a better CDI integration, and in CXF my colleagues work hard on making it better. @Context needs to be continued to be supported though. JAX-RS is

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.

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

@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

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

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

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

Same feeling here. Cheers Alessio

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

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

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

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

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,

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

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: