Date   

Re: CDI integration

Guillermo González de Agüero
 

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 break applications.

For Java EE application servers, I think it can be safely forced though.

Any CDI expert can confirm the extension with the BeforeBeanDiscovery observer I proposed would work here? It that case, the spec would not need the dependency (only on EE servers implementations would be required to support it).


Regards,

Guillermo González de Agüero

El sáb., 3 de junio de 2017 10:44, Markus KARG <markus@...> escribió:

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% backwards compatible.

* JAX-RS 2.2: Container SHOULD provide CDI, but MUST be 100% backwards compatible.

* JAX-RS 2.3: Container MUST provide CDI, but MUST be 100% backwards compatible; Old DI is marked as deprecated.

* JAX-RS 2.4: Container MUST provide CDI, but MAY still provide old annotations; Old DI is marked as deprecated and pruning date is told (JAX-RS 3.0).

* JAX-RS 3.0: Container MUST provide CDI, but SHOULD NOT still provide old annotations; Old DI is officially pruned.

* JAX-RS 3.1: Container MUST provide CDI, but MUST NOT still provide old annotations; Old DI is finally gone.

 

-Markus

 

From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Arjan Tijms
Sent: Freitag, 2. Juni 2017 21:17


To: jaxrs-spec@javaee.groups.io
Subject: Re: [jaxrs] CDI integration

 

Hi,

 

On Fri, Jun 2, 2017 at 7:03 PM, Sergey Beryozkin <sberyozkin@...> wrote:

Makes sense as long as CDI is not mandatory for 2.1.

 

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

 

We deprecated @ManagedBean for JSF 2.3, and I hope to be able and given permission to totally prune it in a future release. JSF is already big enough and should concentrate on the web framework and UI components part without being slowed down and bloated by also having to maintain its own DI engine.

 

I can't imagine the same wouldn't hold for JAX-RS to some degree. Why maintain an entire independent DI engine if there's one in the platform that you can just use, or outside the platform can just bundle?

 

Kind regards,

Arjan Tijms

 

 

 

 


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 see some won't have a problem at all if JAX-RS becomes owned truly and finally by EE only, I'm not going to keep spending my time any longer on this argument


On 02/06/17 17:43, Markus KARG wrote:

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 conditional, which also means to break things in some cases!

 

You can still support the old annotations to keep old code running on JAX-RS 2.x, but we should allow to write new applications using latest technology, and we should push people into using latest stuff by _deprecating_ old annotations starting with JAX-RS 3.x.

 

From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Sergey Beryozkin
Sent: Freitag, 2. Juni 2017 18:31
To: jaxrs-spec@javaee.groups.io
Subject: Re: [jaxrs] CDI integration

 

So lets us just break everything and be happy, how inspiring...
On 02/06/17 17:29, Markus KARG wrote:

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 specification as being mandatory. For me, CDI is such a fundamental API that I even would love to have it being part of Java SE !

 

From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Sergey Beryozkin
Sent: Freitag, 2. Juni 2017 17:34
To: jaxrs-spec@javaee.groups.io
Subject: Re: [jaxrs] CDI integration

 

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 and it is in our interests to ensure it does not happen.
Lets do the best CDI integration ever but avoid losing the 'independence' of the core JAX-RS API.

Cheers, Sergey
On 02/06/17 16:32, Pavel Bucek wrote:

consider this as a subthread :)

 

On 02/06/2017 16:27, Guillermo González de Agüero wrote:

Ad @Stereotype - I'd need to check whether we can easily do that, since it would create a dependency on javax.enterprise.inject. I don't understand the remark about that annotation not being there in the runtime - it will be there, it has retention runtime (otherwise it wouldn't work)

I meant CDI will only be needed at (JAX-RS implementation) compile time. Applications won't need it as annotations not present on the classpath are just erased at runtime. So people using Spring or wathever non-CDI framework won't see any difference. Hope it clearer now?


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 info, I wasn't aware of this behavior.

There is a little (forward) issue with this - similarly to any other "optional" dependency, there will be issues with this when Java 9 modules are used. Once the dependency on CDI API is declared in JAX-RS API module-info, CDI API will be required on the module path of any JAX-RS enabled app/code (at least for compilation).

Not saying that is a deal breaker, it's just something we need to consider.

Regards,
Pavel

 

 

 

 


Re: module-info or not module-info..

Gunnar Morling
 

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 non-modularized JAR be used as an automatic module (instead of deriving a module name from the JAR file name). The change for this hasn't landed int the latest JDK 9 preview release yet (b172 at the time of writing), but once it will, we'd make use of this for Bean Validation. I don't think there's any risk of adding this header, esp. it can be done while building with Java 8.


Re: module-info or not module-info..

Pavel Bucek
 

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


On 03/06/2017 08:11, Ivar Grimstad wrote:
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 include it now as it may change then depending on how that goes.

Ivar

On Fri, Jun 2, 2017 at 6:55 PM Andy McCright <andymc@...> wrote:
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 whether to include a module-info for a 2.1.1 maintenance release.  If JPMS is on by default when Java 9 ships, I would be in favor of including it in the maintenance release.
 
Thanks,
 
Andy

J. Andrew McCright
IBM WebSphere Development
+1 507 253 7448
TL 553-7448
andymc@...
 
 
----- Original message -----
From: "Markus KARG" <markus@...>
Sent by: jaxrs-spec@javaee.groups.io
To: jaxrs-spec@javaee.groups.io
Cc:
Subject: Re: [jaxrs] module-info or not module-info..
Date: Fri, Jun 2, 2017 11:26 AM
 
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 Java SE still will be 8. Target platforms for JAX-RS 2.1 are Java SE 8 and Java EE 8. So I do neither see a need nor any real benefit for prematurely supporting Java SE 9. It would imply a risk, even if a small one, so we should abstain from that.

It think it would be wise also, not to include Java SE 9 support in JAX-RS 2.1.1. Instead, we should plan to provide Java 9 support in JAX-RS 3, but right now start to work on that once JAX-RS 2.1 is released.

-Markus

-----Original Message-----
From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Pavel Bucek
Sent: Freitag, 2. Juni 2017 16:38
To: jaxrs-spec@javaee.groups.io
Subject: [jaxrs] module-info or not module-info..

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, Java SE 9 was postponed and the JAX-RS release will most likely happen before that date.

Should we include compiled module-info, even when the compilation was done by early access build of JDK 9? I would believe that there won't be any change in the bytecode format, but it could happen..

 From my point of view, it might be better to NOT include compiled module-info now and (if demanded), release JAX-RS 2.1.1 (or something like that) with updated API jar.

Any thoughts/comments?

Thanks,
Pavel







 
 

--

Java Champion, JCP EC/EG Member, JUG Leader



Re: module-info or not module-info..

Pavel Bucek
 

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 not sure whether the header name is final or not :)

I guess we can ask around about this - as you say, introducing manifest entry is not a problem.

Thanks,
Pavel

On 03/06/2017 12:39, Gunnar Morling via Groups.Io wrote:
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 non-modularized JAR be used as an automatic module (instead of deriving a module name from the JAR file name). The change for this hasn't landed int the latest JDK 9 preview release yet (b172 at the time of writing), but once it will, we'd make use of this for Bean Validation. I don't think there's any risk of adding this header, esp. it can be done while building with Java 8.


Re: Status update

Pavel Bucek
 

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 still not sure whether we want to add these as client builder methods or as a properties and if latter, where the properties should be defined. The issue is on my list, but I cannot promise that it will be part of the next milestone build.

Regards,
Pavel


On 03/06/2017 10:22, Dennis Kieselhorst wrote:
Hi Pavel,

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

Cheers
Dennis


Re: CDI integration

Pavel Bucek
 

Hi Guillermo,

The only caveat is that the implementation will need to know the classes by that point, which is before ServletContainerInitializer is fired
that certainly is a problem, we do rely on servlet scanning..

Regards,
Pavel


On 02/06/2017 19:11, Guillermo González de Agüero wrote:
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 http://www.next-presso.com/2017/02/nobody-expects-the-cdi-portable-extensions/):

public class JaxRsExtension implements Extension {
   
    public void addClasses(@Observes BeforeBeanDiscovery bbd) {
        bbd.addAnnotatedType(RestResource.class, RestResource.class.getName()).
                add(RequestScoped.Literal.INSTANCE);
    }
}


The only caveat is that the implementation will need to know the classes by that point, which is before ServletContainerInitializer is fired (I'm not sure that's a problem; just stating so implementers may comment on it). That prevents the hard dependency on CDI, making everyone happy.

Thoughts?


Regards,

Guillermo González de Agüero


On Fri, Jun 2, 2017 at 5:32 PM, Pavel Bucek <pavel.bucek@...> wrote:

consider this as a subthread :)


On 02/06/2017 16:27, Guillermo González de Agüero wrote:

Ad @Stereotype - I'd need to check whether we can easily do that, since it would create a dependency on javax.enterprise.inject. I don't understand the remark about that annotation not being there in the runtime - it will be there, it has retention runtime (otherwise it wouldn't work)

I meant CDI will only be needed at (JAX-RS implementation) compile time. Applications won't need it as annotations not present on the classpath are just erased at runtime. So people using Spring or wathever non-CDI framework won't see any difference. Hope it clearer now?

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 info, I wasn't aware of this behavior.

There is a little (forward) issue with this - similarly to any other "optional" dependency, there will be issues with this when Java 9 modules are used. Once the dependency on CDI API is declared in JAX-RS API module-info, CDI API will be required on the module path of any JAX-RS enabled app/code (at least for compilation).

Not saying that is a deal breaker, it's just something we need to consider.

Regards,
Pavel



Re: Status update

Gunnar Morling
 

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 <pavel.bucek@...>:

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 integration
- HTTP PATCH support on the server (client side was just reverted)
- CompletionStage can be returned from the resource method
- Response API: AutoCloseable + Status#asEnum
- Support for new HTTP Status codes

Etc.

Complete list of closed issues:

https://github.com/jax-rs/api/issues?q=is%3Aissue+is%3Aclosed+sort%3Aupdated-desc

API commits:

https://github.com/jax-rs/api/commits/master

Spec commits:

https://github.com/jax-rs/spec/commits/master

If you have any questions or suggestions about changes we've made, please
let us know.

We are going to release another API milestone build soon and it will be most
likely last milestone before submitting Proposed Final Draft.

Thanks and regards,
Pavel




Re: Status update

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 latest version of the proposal, L3 will be chosen - what happens when L3 is passed to BV?

Producing an error? Using a default Locale? Neither is a good behavior, L2 should be selected. I haven't seen anything in BV which would return set of supported locales..

Also, the selected locale (whatever it is), should be made available to JAX-RS application, so it can work with that further if needed. We don't have anything like that now. Not to mention that the selection process might need to be pluggable.

Last but not least - we would need to define how is the selected Locale used in whole context of JAX-RS application, which might sound easier as it is.

Best regards,
Pavel

On 05/06/2017 10:06, Gunnar Morling via Groups.Io wrote:
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 <pavel.bucek@...>:
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 integration
- HTTP PATCH support on the server (client side was just reverted)
- CompletionStage can be returned from the resource method
- Response API: AutoCloseable + Status#asEnum
- Support for new HTTP Status codes

Etc.

Complete list of closed issues:

https://github.com/jax-rs/api/issues?q=is%3Aissue+is%3Aclosed+sort%3Aupdated-desc

API commits:

https://github.com/jax-rs/api/commits/master

Spec commits:

https://github.com/jax-rs/spec/commits/master

If you have any questions or suggestions about changes we've made, please
let us know.

We are going to release another API milestone build soon and it will be most
likely last milestone before submitting Proposed Final Draft.

Thanks and regards,
Pavel




Re: Status update

Pavel Bucek
 

On 04/06/2017 23:15, Pavel Bucek wrote:

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 still not sure whether we want to add these as client builder methods or as a properties and if latter, where the properties should be defined. The issue is on my list, but I cannot promise that it will be part of the next milestone build.

Regards,
Pavel


On 03/06/2017 10:22, Dennis Kieselhorst wrote:
Hi Pavel,

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

Cheers
Dennis



Re: Status update

 

Hey Pavel,

thanks a lot. It is great to finally see this feature in the spec.

Just one minor typo: "withing" should be "within". See:


Christian


2017-06-05 21:13 GMT+02:00 Pavel Bucek <pavel.bucek@...>:

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


On 04/06/2017 23:15, Pavel Bucek wrote:

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 still not sure whether we want to add these as client builder methods or as a properties and if latter, where the properties should be defined. The issue is on my list, but I cannot promise that it will be part of the next milestone build.

Regards,
Pavel


On 03/06/2017 10:22, Dennis Kieselhorst wrote:
Hi Pavel,

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

Cheers
Dennis






Re: Status update

Pavel Bucek
 

oops. :) will be fixed in the next milestone.

Thanks,
Pavel


On 06/06/2017 06:27, Christian Kaltepoth wrote:
Hey Pavel,

thanks a lot. It is great to finally see this feature in the spec.

Just one minor typo: "withing" should be "within". See:


Christian


2017-06-05 21:13 GMT+02:00 Pavel Bucek <pavel.bucek@...>:

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


On 04/06/2017 23:15, Pavel Bucek wrote:

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 still not sure whether we want to add these as client builder methods or as a properties and if latter, where the properties should be defined. The issue is on my list, but I cannot promise that it will be part of the next milestone build.

Regards,
Pavel


On 03/06/2017 10:22, Dennis Kieselhorst wrote:
Hi Pavel,

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

Cheers
Dennis





--


Re: Status update

Dennis Kieselhorst
 

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


Re: Status update

Gunnar Morling
 

Hi Pavel,

2017-06-05 11:07 GMT+02:00 Pavel Bucek <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 latest version of the
proposal, L3 will be chosen - what happens when L3 is passed to BV?
The fallback mechanism of the JDK ResourceBundle API will kick in
which depends on the relationship between requested locales.

So say L3 = EN_US and L2 = EN, the ResourceBundle API automatically
will take care of that fallback and use EN if no messages for EN_US
are present. If L2 was something unrelated, e.g. FR then it'd fall
back to the default messages in whatever language defined by the user
(and in English as measure of last resort for the built-in
constraints).


Producing an error? Using a default Locale? Neither is a good behavior, L2
should be selected. I haven't seen anything in BV which would return set of
supported locales..
I thought that's where the suggested LocaleResolver SPI comes in. The
user will know in which languages they have provided validation
messages, so they could plug in an alternative LocaleResolver which
could select L2 over L3 in your example.


Also, the selected locale (whatever it is), should be made available to
JAX-RS application, so it can work with that further if needed. We don't
have anything like that now. Not to mention that the selection process might
need to be pluggable.
Isn't that what the LocalResolver SPI exactly is about?


Last but not least - we would need to define how is the selected Locale used
in whole context of JAX-RS application, which might sound easier as it is.

Best regards,
Pavel



On 05/06/2017 10:06, Gunnar Morling via Groups.Io wrote:

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 <pavel.bucek@...>:

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 integration
- HTTP PATCH support on the server (client side was just reverted)
- CompletionStage can be returned from the resource method
- Response API: AutoCloseable + Status#asEnum
- Support for new HTTP Status codes

Etc.

Complete list of closed issues:


https://github.com/jax-rs/api/issues?q=is%3Aissue+is%3Aclosed+sort%3Aupdated-desc

API commits:

https://github.com/jax-rs/api/commits/master

Spec commits:

https://github.com/jax-rs/spec/commits/master

If you have any questions or suggestions about changes we've made, please
let us know.

We are going to release another API milestone build soon and it will be
most
likely last milestone before submitting Proposed Final Draft.

Thanks and regards,
Pavel






Re: CDI integration

Ondrej Mihályi
 

>> The only caveat is that the implementation will need to know the classes by that point, which is before ServletContainerInitializer is fired
that certainly is a problem, we do rely on servlet scanning..
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 resources only want to inject beans from other modules).

The approach of turning @Path into a stereotype is very nice and it doesn't require a runtime dependency on CDI at all. CDI API would be needed only to compile JAX-RS API because annotations not found on the classpath are ignored by the JVM, CDI impl wouldn't be needed at all. If we specify @RequestScoped in the stereotype, it would just specify what I believe all implementations do anyway -> create a resource instance per request, which is the default behavior mandated by the previous JAX-RS 2.0
It would be possible to override the scope for each class in a standard way by providing a scope annotation along with @Path.

Furthermore, if @Path is a stereotype, it would also become a bean-defining annotation and turn on CDI by default, even if there are no other CDI beans in the module, which is what most people would expect.

Ondro


Re: CDI integration

Ondrej Mihályi
 

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 where applicable (naturally everywhere except method parameters).

Ondro


Re: CDI integration

Ondrej Mihályi
 

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


Re: CDI integration

 

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

 

From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Ondrej Mihályi
Sent: Dienstag, 6. Juni 2017 16:27
To: jaxrs-spec@javaee.groups.io
Subject: Re: [jaxrs] CDI integration

 

>> The only caveat is that the implementation will need to know the classes by that point, which is before ServletContainerInitializer is fired

that certainly is a problem, we do rely on servlet scanning..

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 resources only want to inject beans from other modules).

The approach of turning @Path into a stereotype is very nice and it doesn't require a runtime dependency on CDI at all. CDI API would be needed only to compile JAX-RS API because annotations not found on the classpath are ignored by the JVM, CDI impl wouldn't be needed at all. If we specify @RequestScoped in the stereotype, it would just specify what I believe all implementations do anyway -> create a resource instance per request, which is the default behavior mandated by the previous JAX-RS 2.0
It would be possible to override the scope for each class in a standard way by providing a scope annotation along with @Path.

Furthermore, if @Path is a stereotype, it would also become a bean-defining annotation and turn on CDI by default, even if there are no other CDI beans in the module, which is what most people would expect.

Ondro


CDI integration - decision

Pavel Bucek
 

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 that providing a better CDI integration would require more experimentation than what we can do in this minor release. We also don't want to introduce "hard" dependency on CDI API to the JAX-RS API as many JAX-RS developers rely on running JAX-RS outside of CDI context.

We agree that CDI can be used as the "glue" of the whole Java EE platform and JAX-RS can do more in terms of the CDI integration when running in a Java EE container. Currently, such enhancements are NOT forbidden at the spec level and JAX-RS providers are free to introduce support that goes beyond what JAX-RS spec mandates. Further experiment in this area can help to gather more feedback for any future re-evaluation of improved CDI/JAX-RS integration story. Also, this feedback may help CDI owners to provide public API enhancements to enable full JAX-RS /CDI integration in a portable way.

Thanks again for the discussion on the mailing list.

Best regards,
Pavel & Santiago


Re: CDI integration - decision

Guillermo González de Agüero
 

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 integrate with CDI.

CDI 2.0 is already final but maybe they have some ideas that could help here going some step foward. I ask you and Santiago and the rest of the EG please to wait a little for them to comment here before taking a definitive decission.


Regards,

Guillermo González de Agüero

On Tue, Jun 6, 2017 at 5:47 PM, Pavel Bucek <pavel.bucek@...> wrote:
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 that providing a better CDI integration would require more experimentation than what we can do in this minor release. We also don't want to introduce "hard" dependency on CDI API to the JAX-RS API as many JAX-RS developers rely on running JAX-RS outside of CDI context.

We agree that CDI can be used as the "glue" of the whole Java EE platform and JAX-RS can do more in terms of the CDI integration when running in a Java EE container. Currently, such enhancements are NOT forbidden at the spec level and JAX-RS providers are free to introduce support that goes beyond what JAX-RS spec mandates. Further experiment in this area can help to gather more feedback for any future re-evaluation of improved CDI/JAX-RS integration story. Also, this feedback may help CDI owners to provide public API enhancements to enable full JAX-RS /CDI integration in a portable way.

Thanks again for the discussion on the mailing list.

Best regards,
Pavel & Santiago






Re: CDI integration

Santiago Pericas-Geertsen
 


On Jun 6, 2017, at 11:42 AM, Markus KARG <markus@...> wrote:

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

 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 that just as important is to ensure backward compatibility; adoption of newer versions of Java EE and JAX-RS depend on this compatibility not being threatened.

— Santiago

 
From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Ondrej Mihályi
Sent: Dienstag, 6. Juni 2017 16:27
To: jaxrs-spec@javaee.groups.io
Subject: Re: [jaxrs] CDI integration
 
>> The only caveat is that the implementation will need to know the classes by that point, which is before ServletContainerInitializer is fired
that certainly is a problem, we do rely on servlet scanning..
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 resources only want to inject beans from other modules).

The approach of turning @Path into a stereotype is very nice and it doesn't require a runtime dependency on CDI at all. CDI API would be needed only to compile JAX-RS API because annotations not found on the classpath are ignored by the JVM, CDI impl wouldn't be needed at all. If we specify @RequestScoped in the stereotype, it would just specify what I believe all implementations do anyway -> create a resource instance per request, which is the default behavior mandated by the previous JAX-RS 2.0
It would be possible to override the scope for each class in a standard way by providing a scope annotation along with @Path.

Furthermore, if @Path is a stereotype, it would also become a bean-defining annotation and turn on CDI by default, even if there are no other CDI beans in the module, which is what most people would expect.

Ondro