Topics

CDI integration

Guillermo González de Agüero
 

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,

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?


 

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?





Sebastian Daschner
 

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?




--

Sergey Beryozkin
 

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

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?




--


Arjan Tijms
 

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?




--



Sergey Beryozkin
 

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?




--




Sergey Beryozkin
 

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?




--





Arjan Tijms
 



On Wed, May 31, 2017 at 12:53 PM, Sergey Beryozkin <sberyozkin@...> wrote:
Hi

Lest not dramatize it,
difficult, confusing, all because of @Context ?

Yes.

It's another injection and bean model and doesn't play nice with the platform wide services for things such as extensions, decorators and interceptors.

This is also why we deprecated and native managed beans in JSF.

Java EE is not as good as it could be now, because many specs live on their own little islands.



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

JAX-RS is a part of Java EE, is it not?

Kind regards,
Arjan Tijms

 

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?




--





Arjan Tijms
 

On Wed, May 31, 2017 at 04:00 am, Sergey Beryozkin wrote:
JAX-RS is big in EE but it needs to be present in SpringBoot, etc.

Why?

Sergey Beryozkin
 

On 31/05/17 12:07, Arjan Tijms wrote:


On Wed, May 31, 2017 at 12:53 PM, Sergey Beryozkin <sberyozkin@...> wrote:
Hi

Lest not dramatize it,
difficult, confusing, all because of @Context ?

Yes.

It's another injection and bean model and doesn't play nice with the platform wide services for things such as extensions, decorators and interceptors.

This is also why we deprecated and native managed beans in JSF.

Java EE is not as good as it could be now, because many specs live on their own little islands.



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

JAX-RS is a part of Java EE, is it not?
Technically it is. Not all nderstand though why JAX-RS is one of the most popular EE spec today - let me answer, because the developers
could use it everywhere without having to ensure some EE Managed ExecutorService exists around.

Thanks, Sergey

Kind regards,
Arjan Tijms

 

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?




--






Sergey Beryozkin
 

On 31/05/17 12:09, Arjan Tijms wrote:
On Wed, May 31, 2017 at 04:00 am, Sergey Beryozkin wrote:
JAX-RS is big in EE but it needs to be present in SpringBoot, etc.

Why?

Because this is what non EE users of JAX-RS (and there are many of them) look for (they migrate to Spring Boot and non-EE containers in general).

I've always felt that this ignoring of the fact that major non-EE containers are not thought by many many users is not good, as far as restricting a given (JAX-RS) API is concerned

Cheers, Sergey


Sergey Beryozkin
 

Sorry for the typo, I meant to say that  "ignoring of the fact that major non-EE containers are *now* thought by"

On 31/05/17 12:19, Sergey Beryozkin wrote:
On 31/05/17 12:09, Arjan Tijms wrote:
On Wed, May 31, 2017 at 04:00 am, Sergey Beryozkin wrote:
JAX-RS is big in EE but it needs to be present in SpringBoot, etc.

Why?

Because this is what non EE users of JAX-RS (and there are many of them) look for (they migrate to Spring Boot and non-EE containers in general).

I've always felt that this ignoring of the fact that major non-EE containers are not thought by many many users is not good, as far as restricting a given (JAX-RS) API is concerned

Cheers, Sergey



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?

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?


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

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


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?




--






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?

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?