I do not say we have to break everything. I said we should mandate to _bundle_ CDI if needed. This does not break anything, it provides additional features. Also please remember that JAXB became

So lets us just break everything and be happy, how inspiring...

I would really love to see everything replaced by CDI which is duplicated in any Java EE API. If this means that a JAX-RS implementation has to provide CDI, then we should add this to the

Looking at all the trouble I had with diverse Java 9 pre-releases in the past months, I really think it would be wise to completely ignore Java 9 for now. At the time of releasing JAX-RS 2.1 current

IMHO it would be a deal breaker, please do not make strong deps on CDI in JAX-RS API. It will affect non-EE and non-CDI RI, CXF, RestEasy users who will get annoyed and move elsewhere

consider this as a subthread :) To be absolutely honest, I'd expect CNFE or something like that. I already wrote a test, which corresponds to what you wrote ;) So thanks for that

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

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

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

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

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

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

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

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

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