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

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

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

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

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.

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

Hi Pavel, Any chance for considering the latest proposal for passing the (highest-quality) request locale to Bean Validation? Thanks, --Gunnar 2017-06-02 14:48 GMT+02:00 Pavel Bucek

Hi Gunnar, I'm sorry to say that, but I don't think that proposal is viable. What if the app (BV layer) knows Locales L1 and L2 and the user (request) asks for L3;q=0.9, L2;q=0.5, L1;q=0.1. In the

please seehttps://github.com/jax-rs/api/commit/d18207327468870ab885120c3790e36a741af26d

Hey Pavel, thanks a lot. It is great to finally see this feature in the spec. Just one minor typo: "withing" should be "within".

oops. :) will be fixed in the next milestone. Thanks, Pavel

Hi Pavel, thank you for adding this. I filed the OCA yesterday so next time you should be able to accept my contributions. Regards Dennis

Hi Pavel, 2017-06-05 11:07 GMT+02:00 Pavel Bucek <pavel.bucek@...>: The fallback mechanism of the JDK ResourceBundle API will kick in which depends on the relationship between requested

Even it wouldn't be a problem, if @Path annotation isn't a bean defining annotation, the event wouldn't be fired at all in the "annotated" discovery mode if there are no other CDI beans (possible if

Regarding the dependency on CDI, I don't think that JAX-RS must depend on CDI at runtime at this stage. However, it could at least depend on @Inject from JSR 330 which should be preferred to @Context

I created an new issue to turn the @Path annotation into a CDI stereotype if used in a CDI container: https://github.com/jax-rs/api/issues/556

Turning on CDI by default implies that all methods have to be non-final, which is not backwards compatible to JAX-RS 2.0. So we cannot do that. -Markus

Dear experts, Thank you for a productive discussion about CDI integration. We now have a good understanding of what can be achieved when using the new CDI 2.0 API. Our recent analysis has concluded

Hi, I invited Antoine Sabot Durand (CDI Spec lead) to join the conversation and he replied me today that he and the Weld team will have a look at the issue as they have already been helping other spec

That's a good point, and certainly not something we can easily resolve. As others have mentioned, a strength of Java EE is integration with other specs like CDI, JSON-B, etc. But let us not forget