Hi Guillermo, that certainly is a problem, we do rely on servlet scanning.. Regards, Pavel

Hi Dennis, I can't even if I wanted to - you are not on the OCA page (http://www.oracle.com/technetwork/community/oca-486395.html), so I cannot accept any code contribution from you.

I'm waiting for the implementation (since I'd like to test it before the actual commit), but the problem is that I do have some experience with "breaking" changes between jdk 9 builds, so I'm

We do have the module name and the content already, see https://github.com/jax-rs/api/blob/master/jaxrs-api/src/main/java/module-info.java

One option to consider is to add the "Automatic-Module-Name" header to the spec JAR's MANIFEST.MF. This header entry is foreseen by JPMS (some background) to specify a module name, should a

Hi, As far as I understand, the module dependency Pavel talked about would just mean that the CDI API would be required to be there, not that it'd require a CDI implementation to work. It wouldn't

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%

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

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

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

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

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.

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

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

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

-1

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

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

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,

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