1. jaxrs-spec@javaee.groups.io
   Date   
Re: CDI integration

Markus KARG
 

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: CDI integration

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

 
Re: CDI integration

Markus KARG
 

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

Markus KARG
 

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
Re: CDI integration

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
Re: CDI integration

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
Re: CDI integration

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?
module-info or not module-info..

Pavel Bucek
 

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
Re: CDI integration

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

[1] http://docs.jboss.org/weld/reference/3.0.0.CR1/en-US/html/stereotypes.html#_default_scope_for_a_stereotype
Re: CDI integration

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?
Re: 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?
Status update

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

Guillermo González de Agüero
 

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?
Re: CDI integration

Pavel Bucek
 

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?
Re: CDI integration

Guillermo González de Agüero
 

Hi,

I agree @Context annotation must still work, at least from the time being. But I see two things here:
- It's easy to handle injection of @Context via CDI with just a custom extension. The spec can force implementations to use CDI for injection of @Context annotated properties only on Java EE application servers. That would still allow non Java EE users to use JAX-RS while making EE more consistent.
- @Inject doesn't equal CDI, but JSR 330, and from what I've seen, Spring already supports it. Deprecating @Context in favor or the standard annotations would still not break Spring Boot users IMO (I haven't used Spring myself so I'm maybe wrong here).


Regards,

Guillermo González de Agüero

Guillermo González de Agüero

On Wed, May 31, 2017 at 1:00 PM, Sergey Beryozkin <sberyozkin@...> wrote:
Let me step back.
+1 to having a better CDI integration, and in CXF my colleagues work hard on making it better.
@Context needs to be continued to be supported though. JAX-RS is big in EE but it needs to be present in SpringBoot, etc.
Wiring CDI into non EE can become problematic thus continuing to have a basic @Context support is good.

Sorry for hajacking the thread

Cheers, Sergey


On 31/05/17 11:53, Sergey Beryozkin wrote:
Hi

Lest not dramatize it,
difficult, confusing, all because of @Context ? I'm not going to comment.

As well as re this 'ownership' claim of JAX-RS by EE.

Sergey
On 31/05/17 11:44, Arjan Tijms wrote:
Hi,

On Wed, May 31, 2017 at 11:52 AM, Sergey Beryozkin <sberyozkin@...> wrote:
@Context is that little thing that has helped to make JAX-RS visible outside of the EE world, as opposed to it be yet another EE spec.

It's not just another EE spec, but one of the fundamental EE specs.

 
Rather than trying to keep JAX-RS more and more dependent on EE pieces I'd like to encourage us keeping it as open as possible

IMHO; open as possible also means that you eventually commit to nothing and only make it more difficult and confusing to use in its primary environment. 

Kind regards.
Arjan Tijms



 
Sergey


On 31/05/17 10:44, Sebastian Daschner wrote:

Yes, agreed.

Especially the ability to @Inject JAX-RS managed objects (basically what is @Context today) would be very helpful. That enables to inject UriInfo within the EE application and also getting rid of @Context to streamline Java EE further :-)

Cheers,
Sebastian
   


On 05/31/2017 03:12 PM, Christian Kaltepoth wrote:
I agree with Guillermo and Arjan that further CDI alignment is very important for JAX-RS. 

It would be great to see some EG discussion about this.

Christian

2017-05-25 20:13 GMT+02:00 Arjan Tijms <arjan.tijms@...>:
Hi,

I too would greatly love to see this happening. CDI alignment IMHO should have been -the- major theme of Java EE and unfortunately too few steps have been made towards that goal.

Kind regards,
Arjan Tijms



On Thu, May 25, 2017 at 8:04 PM, Guillermo González de Agüero <z06.guillermo@...> 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?




--
Christian Kaltepoth
Re: CDI integration

Sergey Beryozkin
 

Hi

It is promising...

Thanks, Sergey

Thanks, Sergey

On 31/05/17 13:21, Arjan Tijms wrote:
Hi,

Thanks for your reply, I see your point although I have a slightly different vision. But for now, let's table that sub-discussion ;)

As for top CDI support or even (in time) fully depending on CDI; this would not have to be a problem for using JAX-RS outside of Java EE. CDI can be very easily added to just about any type of project, and CDI 2.0 even has explicit Java SE support.

Kind regards,
Arjan Tijms


Re: #544: Localization & BeanValidation

Gunnar Morling
 

I see, thanks for clarifying the details, Christian!

To me it seems that'd be a very reasonable default behaviour for
JAX-RS; people still could plug in a custom LocaleResolver based on
their custom requirements and context, e.g. preferring a Locale for
which they provide a resource bundle with validation messages.

2017-05-29 15:36 GMT+02:00 Christian Kaltepoth <christian@kaltepoth.de>:

Hi Gunnar,

sorry, the term "priority" was a bit misleading in this context. Actually it
uses the "quality value" from the "Accept-Language" header.

See:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Language

Christian

2017-05-29 14:26 GMT+02:00 Gunnar Morling via Groups.Io
<gunnar.morling=googlemail.com@groups.io>:

Hi Christian,

The default implementation basically resolves the locale by parsing the
Accept-Locale request header and resolving the locale with the highest
priority.
This seems very useful, pretty much like what could be useful within
JAX-RS itself. That selected Locale could then be used with a
specifically set up message interpolator, just as JSF defines this
integration with Bean Validation.

Out of curiosity, how is that priority be defined?

--Gunnar



2017-05-28 16:00 GMT+02:00 Christian Kaltepoth <christian@kaltepoth.de>:
Hey Pavel,

The struggle here is with the SupportedLanguagesProvider - it feels
like
it should be used for something more than BV - I think it's fair to say
that
if localizaiton of BV error messages is the sole purpose of such
provider,
it shouldn't be introduced. And I can't think of any other sensible use
right now.

I would like to take the opportunity to describe what MVC did to support
internationalization which relates to the issue we are discussing here.
As
MVC builds on top of JAX-RS, this may (or may not) be interesting for
you.

For MVC we identified a few locale-dependent aspects which we had to
support:

Data type conversion as part of the data binding mechanism needs to be
locale aware. So something like @FormParam("price") BigDecimal price
needs
to be parsed according to the number formatting rules of the specific
locale.
Formatting data according to locale dependent rules when rending the
view
(date format / number format). This certainly isn't something relevant
for
JAX-RS.
Generating binding and validation errors message in the specific
language.
This is basically what we are talking about here.

To support these scenarios we defined the term "request locale" as the
locale which is used for any locale-dependent operation within the
lifecycle
of a request. The request locale is resolved for each request using the
following SPI:

public interface LocaleResolver {
Locale resolveLocale(LocaleResolverContext context);
}

The default implementation basically resolves the locale by parsing the
Accept-Locale request header and resolving the locale with the highest
priority.

But developers can customize this by providing their own resolver. So if
the
developer wants to support only a specific subset of locales, he could
simply create a custom resolver and match the supported locales against
the
Accept-Locale header as described in Pavel's previous mail.

You can see the full SPI here:


https://github.com/mvc-spec/mvc-spec/tree/master/api/src/main/java/javax/mvc/locale

All the details are described in the MVC spec document (pages 37-38):

https://github.com/mvc-spec/mvc-spec/raw/master/spec/spec.pdf

I'm not sure if anything described here could be useful for JAX-RS. Of
cause
we (the MVC EG) would be happy to see any of our APIs to be integrated
into
JAX-RS.

Christian


--
Christian Kaltepoth
Blog: http://blog.kaltepoth.de/
Twitter: http://twitter.com/chkal
GitHub: https://github.com/chkal



--
Christian Kaltepoth
Blog: http://blog.kaltepoth.de/
Twitter: http://twitter.com/chkal
GitHub: https://github.com/chkal
Re: CDI integration

Arjan Tijms
 

Hi,

Thanks for your reply, I see your point although I have a slightly different vision. But for now, let's table that sub-discussion ;)

As for top CDI support or even (in time) fully depending on CDI; this would not have to be a problem for using JAX-RS outside of Java EE. CDI can be very easily added to just about any type of project, and CDI 2.0 even has explicit Java SE support.

Kind regards,
Arjan Tijms
Re: CDI integration

Sergey Beryozkin
 

Hi

Sorry, this is not what I meant. On the opposite I think EE is underestimated and many users (like myself) simply do not understand it well.
As I said, I fully support the cause for JAX-RS users get the most out of what EE provides (top CDI support - surely CXF will do it first :-), etc).

But what I also said that as it happens there are strong non EE offerings are also available. Historically, JAX-RS came to the world completely unconstrained, at the cost (from the EE point of view) introducing its own injection mechanism. IMHO this is why JAX-RS is the main competitor today (and a good portion of JAX-RS API is clearly better IMHO) to what for example SpringWS (RS ?) offers.

I'd just to see JAX-RS continuing staying visible and competitive not only in the EE world...

Cheers, Sergey

On 31/05/17 12:38, Arjan Tijms wrote:
Sergey,

I think what you're saying here is that because some users think Java EE is not good, we as Java EE people should partially abandon it instead of making it better?

Maybe the entire reason that some people think Java EE is not so good is because it's not really integrated well?


Re: CDI integration

Arjan Tijms
 

Sergey,

I think what you're saying here is that because some users think Java EE is not good, we as Java EE people should partially abandon it instead of making it better?

Maybe the entire reason that some people think Java EE is not so good is because it's not really integrated well?
161 - 180 of 266  
More
Home Messages Hashtags About Features Pricing Updates Terms Help Twitter