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

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

Why?

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

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

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

Sergey, I think what you're saying here is that because some users think Java EE is not good, we as Java EE people should partially abandon it instead of making it better? Maybe the entire reason that

Hi Sorry, this is not what I meant. On the opposite I think EE is underestimated and many users (like myself) simply do not understand it well. As I said, I fully support

Hi, Thanks for your reply, I see your point although I have a slightly different vision. But for now, let's table that sub-discussion ;) As for top CDI support or even (in time) fully depending on

I see, thanks for clarifying the details, Christian! To me it seems that'd be a very reasonable default behaviour for JAX-RS; people still could plug in a custom LocaleResolver based on their custom

Hi It is promising... Thanks, Sergey Thanks, Sergey

Hi, I agree @Context annotation must still work, at least from the time being. But I see two things here: - It's easy to handle injection of @Context via CDI with just a custom extension. The spec can

Hello Guillermo, ad "when running on a Java EE Application Server/when CDI is available, resources and providers MUST be available for CDI extensions to process it, just like if had

Hi Pavel, It's not currently doable right now with the standard APIs. My original proposal was to require the application server to do it in a vendor specific manner. WildFly already does it that way

Dear experts, as you might have noticed, we dealt with several small issues in the past couple of weeks. Notable ones: - @Priority for providers - JSON-B integration update - Introduction of JSON-P

Hi Guillermo, this is problematic at least. If there is no API in the CDI spec for requested feature, it would mean that the spec depends on an implementation feature of CDI container

Hi, While I agree this is not ideal, it's certainly not unprecedented in Java EE. More than a few specs depend on such integration code, typically via a product specific SPI that the application

Hi Pavel, First, thanks for taking the time to consider this. Arjan has summarized the idea. With this option, JAX-RS implementations themselves will stay the same as today. Taking Jersey as an

Dear experts, we originally intended to include compiled module-info to JAX-RS API jar. Original plan was to prepare a release on final or "almost" final Java SE 9 compliant JDK. As you might know,

Hi again, It might me possible to register the resources to CDI with the BeforeBeanDiscovery#addAnnotatedType() method [1], provided that the JAX-RS runtime knows its resources by the time CDI fires