Topics

CDI integration


Pavel Bucek
 

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 (I believe it is Weld in this case). What if someone would like to run against different CDI implementation?

That would force JAX-RS implementations to create container specific code for each container which it wants to integrate with. I do see that it might not be a problem for some implementations, especially when there is some impl which is designated to live only in single specific container, but generally it could potentially limit some JAX-RS implementers.

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). Maybe you meant that it won't be necessary to add it to JAX-RS Resource, which already has @Path annotation. Also, @RequestScoped would need to be added as well, since JAX-RS resources are request scoped by default.

So what if we have

@Stereotype
@RequestScoped
public @interface Path { ... }

and @Path is used as an annotation on a class - is it possible to somehow override the scope to something else?

Also, would it be an issue if @Path is used on a resource method? (which is a valid usecase)

Thanks,
Pavel


On 01/06/2017 20:20, Guillermo González de Agüero wrote:
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 [1]. The work there would most probably fall on CDI integration implementations. That was to prevent changes to the JAX-RS api.

But there's also a standard way that would work, and that's marking annotating @Path with @Stereotype. Doing that will make CDI discover resources, without any more side effect I'm aware of. Should a future version decide resources should be request scoped, adding the @RequestScoped annotation to it will do the work.

JSF already did something pretty similar with Converters, but with the @Qualifier annotation [2].

Given how annotations work on Java, it wouldn't be a problem for non CDI users not having those annotations on the classpath; they will just not exist at runtime.

Do you think that's feasible?


Regards,

Guillermo González de Agüero.

[1] https://github.com/wildfly/wildfly/blob/master/jaxrs/src/main/java/org/jboss/as/jaxrs/deployment/JaxrsAnnotationProcessor.java#L48
[2] https://github.com/javaserverfaces/mojarra/blob/2fe586e0b9b23a11b9168b30610b2afadeecdb41/impl/src/main/java/javax/faces/convert/FacesConverter.java#L100

Guillermo González de Agüero

On Thu, Jun 1, 2017 at 10:56 AM, Pavel Bucek <pavel.bucek@...> wrote:

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 a CDI bean defining annotation"

How that can be done? (yes, I'm looking for code example).

Thanks,
Pavel


On 25/05/2017 20:04, Guillermo González de Agüero wrote:
Hi,

Time is quickly running out, and I guess what the plans are regarding CDI alignment. There's an open issue [1] labeled as "2.1-candidate" but it seems no work has been done on that yet.

Given the time and resource limits the EG has, I propose to simply add a note to the spec saying that "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 a CDI bean defining annotation", e.g.: providers and resources are discovered by the CDI runtime like any other bean, but *they don't need to be treated as beans*. That basically ressembled the behaviour offered by trimmed archives on CDI 2.0 [2].

What we gain with that? Users could easily create an extension to make all the resources @RequestScoped, while maintaining the spec clean (further integration would need more discussion). At the moment it's not possible to do that with CDI [3] and you have to mark all your classes as @Dependent (a practice that is not so uncommon [4]) or mark CDI bean discovery "all"/"trimmed".

How do you see it? Do you think it's viable at this time?




Arjan Tijms
 

Hi,

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

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 (I believe it is Weld in this case). What if someone would like to run against different CDI implementation?

That would force JAX-RS implementations to create container specific code for each container which it wants to integrate with.

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 server vendor (not the product implementator) then implements.

For instance, Mojarra had an SPI for annotation scanning integration, that e.g. GlassFish would then implement when integrating Mojarra into GlassFish.

Sometimes in later releases of the spec the functionality on which the SPI depends becomes available via a standardised API and the SPI can then be removed.

The wording in a spec is then not rarely; "In a Java EE container, spec X has to integrate with spec Y in such and such way".

So outside the Java EE container, i.e. when using some spec on Tomcat, the feature is just not available, and inside a Java EE container the burden is on the container vendor.

Kind regards,
Arjan Tijms



 

I do see that it might not be a problem for some implementations, especially when there is some impl which is designated to live only in single specific container, but generally it could potentially limit some JAX-RS implementers.

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). Maybe you meant that it won't be necessary to add it to JAX-RS Resource, which already has @Path annotation. Also, @RequestScoped would need to be added as well, since JAX-RS resources are request scoped by default.

So what if we have

@Stereotype
@RequestScoped
public @interface Path { ... }

and @Path is used as an annotation on a class - is it possible to somehow override the scope to something else?

Also, would it be an issue if @Path is used on a resource method? (which is a valid usecase)

Thanks,
Pavel


On 01/06/2017 20:20, Guillermo González de Agüero wrote:
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 [1]. The work there would most probably fall on CDI integration implementations. That was to prevent changes to the JAX-RS api.

But there's also a standard way that would work, and that's marking annotating @Path with @Stereotype. Doing that will make CDI discover resources, without any more side effect I'm aware of. Should a future version decide resources should be request scoped, adding the @RequestScoped annotation to it will do the work.

JSF already did something pretty similar with Converters, but with the @Qualifier annotation [2].

Given how annotations work on Java, it wouldn't be a problem for non CDI users not having those annotations on the classpath; they will just not exist at runtime.

Do you think that's feasible?


Regards,

Guillermo González de Agüero.

[1] https://github.com/wildfly/wildfly/blob/master/jaxrs/src/main/java/org/jboss/as/jaxrs/deployment/JaxrsAnnotationProcessor.java#L48
[2] https://github.com/javaserverfaces/mojarra/blob/2fe586e0b9b23a11b9168b30610b2afadeecdb41/impl/src/main/java/javax/faces/convert/FacesConverter.java#L100

Guillermo González de Agüero

On Thu, Jun 1, 2017 at 10:56 AM, Pavel Bucek <pavel.bucek@...> wrote:

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 a CDI bean defining annotation"

How that can be done? (yes, I'm looking for code example).

Thanks,
Pavel


On 25/05/2017 20:04, Guillermo González de Agüero wrote:
Hi,

Time is quickly running out, and I guess what the plans are regarding CDI alignment. There's an open issue [1] labeled as "2.1-candidate" but it seems no work has been done on that yet.

Given the time and resource limits the EG has, I propose to simply add a note to the spec saying that "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 a CDI bean defining annotation", e.g.: providers and resources are discovered by the CDI runtime like any other bean, but *they don't need to be treated as beans*. That basically ressembled the behaviour offered by trimmed archives on CDI 2.0 [2].

What we gain with that? Users could easily create an extension to make all the resources @RequestScoped, while maintaining the spec clean (further integration would need more discussion). At the moment it's not possible to do that with CDI [3] and you have to mark all your classes as @Dependent (a practice that is not so uncommon [4]) or mark CDI bean discovery "all"/"trimmed".

How do you see it? Do you think it's viable at this time?





Guillermo González de Agüero
 

Hi Pavel,

First, thanks for taking the time to consider this.

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

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 (I believe it is Weld in this case). What if someone would like to run against different CDI implementation?

That would force JAX-RS implementations to create container specific code for each container which it wants to integrate with. I do see that it might not be a problem for some implementations, especially when there is some impl which is designated to live only in single specific container, but generally it could potentially limit some JAX-RS implementers.

Arjan has summarized the idea. With this option, JAX-RS implementations themselves will stay the same as today. Taking Jersey as an example, if I'm an application server vendor, it will be my job to find a CDI implemenetation that allows me to make @Path behave like a "bean defining annotation". But Jersey won't have nothing to do with it.

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?

Maybe you meant that it won't be necessary to add it to JAX-RS Resource, which already has @Path annotation. Also, @RequestScoped would need to be added as well, since JAX-RS resources are request scoped by default.

So what if we have

@Stereotype
@RequestScoped
public @interface Path { ... }

and @Path is used as an annotation on a class - is it possible to somehow override the scope to something else?

Of course. Annotations directly present on the class take precedence here [1], so noone will see any side effect if they had already defined a different scope.

Also, would it be an issue if @Path is used on a resource method? (which is a valid usecase)

This would not affect it either. CDI only uses stereotypes on beans, so if that method is not annotated also with javax.enterprise.Produces, CDI will not use it. And again, that default scope could be overrided.

Thanks,
Pavel


On 01/06/2017 20:20, Guillermo González de Agüero wrote:
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 [1]. The work there would most probably fall on CDI integration implementations. That was to prevent changes to the JAX-RS api.

But there's also a standard way that would work, and that's marking annotating @Path with @Stereotype. Doing that will make CDI discover resources, without any more side effect I'm aware of. Should a future version decide resources should be request scoped, adding the @RequestScoped annotation to it will do the work.

JSF already did something pretty similar with Converters, but with the @Qualifier annotation [2].

Given how annotations work on Java, it wouldn't be a problem for non CDI users not having those annotations on the classpath; they will just not exist at runtime.

Do you think that's feasible?


Regards,

Guillermo González de Agüero.

[1] https://github.com/wildfly/wildfly/blob/master/jaxrs/src/main/java/org/jboss/as/jaxrs/deployment/JaxrsAnnotationProcessor.java#L48
[2] https://github.com/javaserverfaces/mojarra/blob/2fe586e0b9b23a11b9168b30610b2afadeecdb41/impl/src/main/java/javax/faces/convert/FacesConverter.java#L100

Guillermo González de Agüero

On Thu, Jun 1, 2017 at 10:56 AM, Pavel Bucek <pavel.bucek@...> wrote:

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 a CDI bean defining annotation"

How that can be done? (yes, I'm looking for code example).

Thanks,
Pavel


On 25/05/2017 20:04, Guillermo González de Agüero wrote:
Hi,

Time is quickly running out, and I guess what the plans are regarding CDI alignment. There's an open issue [1] labeled as "2.1-candidate" but it seems no work has been done on that yet.

Given the time and resource limits the EG has, I propose to simply add a note to the spec saying that "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 a CDI bean defining annotation", e.g.: providers and resources are discovered by the CDI runtime like any other bean, but *they don't need to be treated as beans*. That basically ressembled the behaviour offered by trimmed archives on CDI 2.0 [2].

What we gain with that? Users could easily create an extension to make all the resources @RequestScoped, while maintaining the spec clean (further integration would need more discussion). At the moment it's not possible to do that with CDI [3] and you have to mark all your classes as @Dependent (a practice that is not so uncommon [4]) or mark CDI bean discovery "all"/"trimmed".

How do you see it? Do you think it's viable at this time?





Regards,


Guillermo González de Agüero
 

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 this event. If that's the case, my original proposal could easily work. I'll check to make sure.


Regards,

Guillermo González de Agüero

[1] http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#before_bean_discovery

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

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 (I believe it is Weld in this case). What if someone would like to run against different CDI implementation?

That would force JAX-RS implementations to create container specific code for each container which it wants to integrate with. I do see that it might not be a problem for some implementations, especially when there is some impl which is designated to live only in single specific container, but generally it could potentially limit some JAX-RS implementers.

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). Maybe you meant that it won't be necessary to add it to JAX-RS Resource, which already has @Path annotation. Also, @RequestScoped would need to be added as well, since JAX-RS resources are request scoped by default.

So what if we have

@Stereotype
@RequestScoped
public @interface Path { ... }

and @Path is used as an annotation on a class - is it possible to somehow override the scope to something else?

Also, would it be an issue if @Path is used on a resource method? (which is a valid usecase)

Thanks,
Pavel


On 01/06/2017 20:20, Guillermo González de Agüero wrote:
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 [1]. The work there would most probably fall on CDI integration implementations. That was to prevent changes to the JAX-RS api.

But there's also a standard way that would work, and that's marking annotating @Path with @Stereotype. Doing that will make CDI discover resources, without any more side effect I'm aware of. Should a future version decide resources should be request scoped, adding the @RequestScoped annotation to it will do the work.

JSF already did something pretty similar with Converters, but with the @Qualifier annotation [2].

Given how annotations work on Java, it wouldn't be a problem for non CDI users not having those annotations on the classpath; they will just not exist at runtime.

Do you think that's feasible?


Regards,

Guillermo González de Agüero.

[1] https://github.com/wildfly/wildfly/blob/master/jaxrs/src/main/java/org/jboss/as/jaxrs/deployment/JaxrsAnnotationProcessor.java#L48
[2] https://github.com/javaserverfaces/mojarra/blob/2fe586e0b9b23a11b9168b30610b2afadeecdb41/impl/src/main/java/javax/faces/convert/FacesConverter.java#L100

Guillermo González de Agüero

On Thu, Jun 1, 2017 at 10:56 AM, Pavel Bucek <pavel.bucek@...> wrote:

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 a CDI bean defining annotation"

How that can be done? (yes, I'm looking for code example).

Thanks,
Pavel


On 25/05/2017 20:04, Guillermo González de Agüero wrote:
Hi,

Time is quickly running out, and I guess what the plans are regarding CDI alignment. There's an open issue [1] labeled as "2.1-candidate" but it seems no work has been done on that yet.

Given the time and resource limits the EG has, I propose to simply add a note to the spec saying that "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 a CDI bean defining annotation", e.g.: providers and resources are discovered by the CDI runtime like any other bean, but *they don't need to be treated as beans*. That basically ressembled the behaviour offered by trimmed archives on CDI 2.0 [2].

What we gain with that? Users could easily create an extension to make all the resources @RequestScoped, while maintaining the spec clean (further integration would need more discussion). At the moment it's not possible to do that with CDI [3] and you have to mark all your classes as @Dependent (a practice that is not so uncommon [4]) or mark CDI bean discovery "all"/"trimmed".

How do you see it? Do you think it's viable at this time?





Pavel Bucek
 

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


Sergey Beryozkin
 

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



 

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

 


Sergey Beryozkin
 

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

 



 

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

 

 


Sergey Beryozkin
 

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

 

 



Guillermo González de Agüero
 

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



Arjan Tijms
 

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

 

 




Sergey Beryozkin
 

-1

On 02/06/17 20:16, Arjan Tijms wrote:
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

 

 





Arjan Tijms
 

-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 release process, so if we announce it to be pruned for JSF 2.4 (or whatever the new version will be), it will not be actually made optional until JSF 2.5.


Sergey Beryozkin
 

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 dependency. I know many do use CDI with CXF, RI for sure, and very likely RestEasy, which I'm happy with. This relentless push to get CDI as a required dep won't help with the cause of spreading JAX-RS beyond EE boundaries. I've no more energy left to continue this discussion, sorry, glad I'm away for the next week and a bit

Have fun
Sergey  


On 02/06/17 22:12, Arjan Tijms wrote:
-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 release process, so if we announce it to be pruned for JSF 2.4 (or whatever the new version will be), it will not be actually made optional until JSF 2.5.



Arjan Tijms
 

Hi,

On Fri, Jun 2, 2017 at 11:32 PM, Sergey Beryozkin <sberyozkin@...> wrote:
Why are we talking about JSF?

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 also has its own DI engine, separate from the Spring platform's bean container? If not, why should Java EE have that?

And if JAX-RS needs to have its own DI engine, why should JSF not have its own? And then Servlet its own? And JPA its own? Does every spec in Java EE need its own and totally different Di engine? 

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

Imagine how well JAX-RS could do -with- CDI. I absolutely love JAX-RS and so do many people, but I've rarely heard of anyone going for JAX-RS just because of it's fabulous own DI engine.

 
I know many do use CDI with CXF, RI for sure, and very likely RestEasy, which I'm happy with. This relentless push to get CDI as a required dep won't help with the cause of spreading JAX-RS beyond EE boundaries.

Is Spring trying to spread Spring MVC beyond EE boundaries? Is Microsoft trying to spread ASP.NET Web API beyond the .NET boundaries? Is Ruby On Rails trying to spread its REST API beyond RoR boundaries? Or are they all trying to integrate it in their framework as well as they possibly can?

Kind regards,
Arjan Tijms





 
I've no more energy left to continue this discussion, sorry, glad I'm away for the next week and a bit

Have fun
Sergey  


On 02/06/17 22:12, Arjan Tijms wrote:
-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 release process, so if we announce it to be pruned for JSF 2.4 (or whatever the new version will be), it will not be actually made optional until JSF 2.5.




Sebastian Daschner
 

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.

That said CDI / JSR 330 is (and IMO should be) the way of how to @Inject any managed objects into anywhere the developers like. JSF is a good example. Another one is @EJB vs @Inject.

Cheers,
Sebastian
   

On 06/03/2017 06:56 AM, Arjan Tijms wrote:
Hi,

On Fri, Jun 2, 2017 at 11:32 PM, Sergey Beryozkin <sberyozkin@...> wrote:
Why are we talking about JSF?

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 also has its own DI engine, separate from the Spring platform's bean container? If not, why should Java EE have that?

And if JAX-RS needs to have its own DI engine, why should JSF not have its own? And then Servlet its own? And JPA its own? Does every spec in Java EE need its own and totally different Di engine? 

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

Imagine how well JAX-RS could do -with- CDI. I absolutely love JAX-RS and so do many people, but I've rarely heard of anyone going for JAX-RS just because of it's fabulous own DI engine.

 
I know many do use CDI with CXF, RI for sure, and very likely RestEasy, which I'm happy with. This relentless push to get CDI as a required dep won't help with the cause of spreading JAX-RS beyond EE boundaries.

Is Spring trying to spread Spring MVC beyond EE boundaries? Is Microsoft trying to spread ASP.NET Web API beyond the .NET boundaries? Is Ruby On Rails trying to spread its REST API beyond RoR boundaries? Or are they all trying to integrate it in their framework as well as they possibly can?

Kind regards,
Arjan Tijms





 
I've no more energy left to continue this discussion, sorry, glad I'm away for the next week and a bit

Have fun
Sergey  


On 02/06/17 22:12, Arjan Tijms wrote:
-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 release process, so if we announce it to be pruned for JSF 2.4 (or whatever the new version will be), it will not be actually made optional until JSF 2.5.





 

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 Java SE 8 and Java EE 8).

 

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

 

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

 

 

 


 

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

 

 

 

 


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