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

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

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

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

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

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

I agree that we should not ship the module-info in 2.1. I do think it is important that JAX-RS 2.1 should function in Java 9 out-of-the-box though. So, I would advise a wait-and-see approach for

Makes sense as long as CDI is not mandatory for 2.1. I'm not sure you've heard what I was trying to say about the importance of keeping the core JAX-RS as neutral as possible,

Hi, I've checked it and adding a new bean with CDI 2.0 is just as simple as creating an extension like this (taken from

Hi, IMHO it would be best to just commit and make CDI mandatory. This is exactly what we've been in doing in JSF as well. There's a transition period, sure, but in the end things should be a lot

-1

Can you give me any good reason why we should keep @ManagedBean? It has been deprecated already and everything in and around it has been superseded by CDI. Also remember that pruning is a multi

Why are we talking about JSF ? All JAX-RS stacks have been doing very well so far as far taking care of their users, and somehow they have managed to do it without CDI being a required

Hi, Because it's another Java EE spec that had its own DI engine and gave it up for the platform one. I'm really not sure why the REST API of Java EE should have its own DI engine. Does Spring MVC

Fully agree that we should try to align JAX-RS into Java EE (i.e. CDI here) as much as possible. IMO one of the biggest advantages of EE is how the different specs integrate with eachother.

As I recall there were some discussion on the javaee-spec mailinglist (java.net) in May regarding standardzing the module names for the Java EE specs in Java EE 9. So it may be a bit premature to

I fully agree to the comments already posted. Including a compiled module-info now seems to be too risky. JAX-RS should wait for some recommendation from the umbrella spec before integrating

Hi Pavel, could you merge my PR before the next milestone release? https://github.com/jax-rs/api/pull/555 Cheers Dennis

CDI must not be mandatory for the application programmer (so old code does not break), but it is OK for me to make it mandatory to be provided by the container (so new code can safely use it on both

I think this all is a question of the time frame so application programmers and container providers can plan the migration. Proposal: * JAX-RS 2.1: Container MAY provide CDI, but MUST be 100%