Deprecating JAX-RS-specific annotations in favor of CDI

[glassfishrobot]

Latest CDI specifications allows to use CDI with Java SE. Some JAX-RS specific annotations duplicate ideas also covered by CDI annotations.

For long term, it makes sense to use CDI instead of proprietary annotations. To start this process, the JAX-RS EG should identify which annotations can be replaced by CDI, and mark them as deprecated.

[glassfishrobot]

• Issue Imported From: https://github.com/jax-rs/api/issues/569
• Original Issue Raised By:@mkarg
• Original Issue Assigned To: Unassigned

[andymc12]

@mkarg, per our discussion on PR #608, I think it might be good to change this issue's milestone to 2.2. The idea is to deprecate the some of the JAX-RS-specific annotations and replace them with optional CDI annotations. That would allow removal of the JAX-RS-specific annotations in the 3.0 release.

So in the 2.2 release the JAX-RS spec would support both @Context and @Inject - CDI is optional in the sense that users would not need to use CDI at all, but vendors would be required to support CDI if the vendor also makes CDI available. The JAX-RS 2.1 spec does something similar regarding JSON-B providers (vendors are required to supply a JSON-B provider if they already supply a JSON-B implementation). This allows JAX-RS-only vendors (like Jersey, CXF, RestEasy, etc.) to continue operating like 2.1 (no need to recognize CDI annotations), but full Java EE / Jakarta EE vendors (like Liberty, WildFly, etc.) would need to support both injection mechanisms.

[mkarg]

@andymc12 I tend to +1 for this but I am not fully conviced, because @spericas wrote that @context and @Inject are not fully compatible. We should give it a deeper thought before pulling this into 2.2. Particularly I would be more happy if all vendors would give a short statement if they really want to do this in short term, because I do not want to delay 2.2 just for the sake of some troubles with CDI discovered too late.

[arjantijms]

@andymc12

I think it might be good to change this issue's milestone to 2.2. The idea is to deprecate the some of the JAX-RS-specific annotations and replace them with optional CDI annotations. That would allow removal of the JAX-RS-specific annotations in the 3.0 release.

+1

A CDI first approach for all EE specs (thus including JAX-RS) is favoured by Payara.

[chkal]

I'm also +1 for this. But I agree with @mkarg, that the incompatibilities between @Context and @Inject mentioned by @spericas should be discussed in detail.

[ggam]

+1. This was my goal for JAX-RS 2.1 but unfortunately the concern was raised too late to fit the schedule. At that time I emailed Antoine Sabot Durand to ask some questions regarding this CDI integration and he seemed to be interested in helping. I think we could count with him now again. El jue., 31 may. 2018 16:31, Andy McCright <notifications@github.com> escribió:

…

@mkarg <https://github.com/mkarg>, per our discussion on PR #608 <#608>, I think it might be good to change this issue's milestone to 2.2. The idea is to deprecate the some of the JAX-RS-specific annotations and replace them with *optional* CDI annotations. That would allow removal of the JAX-RS-specific annotations in the 3.0 release. So in the 2.2 release the JAX-RS spec would support both @context and @Inject - CDI is optional in the sense that users would not need to use CDI at all, but vendors would be required to support CDI if the vendor also makes CDI available. The JAX-RS 2.1 spec does something similar regarding JSON-B providers (vendors are required to supply a JSON-B provider if they already supply a JSON-B implementation). This allows JAX-RS-only vendors (like Jersey, CXF, RestEasy, etc.) to continue operating like 2.1 (no need to recognize CDI annotations), but full Java EE / Jakarta EE vendors (like Liberty, WildFly, etc.) would need to support both injection mechanisms. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#569 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACAucEMDA039wSPsTxUBwSiZNn88l_FIks5t3_7BgaJpZM4UVJ2E> .

[arjantijms]

Hi,

On Thu, May 31, 2018 at 7:47 PM, Christian Kaltepoth < ***@***.***> wrote: I'm also +1 for this. But I agree with @mkarg <https://github.com/mkarg>, that the incompatibilities between @context and @Inject mentioned by @spericas <https://github.com/spericas> should be discussed in detail.

It would be good to discuss indeed what @context can do (if anything) that CDI can't. In JSF we're busy with a similar switchover. We introduced CDI versions for existing JSF DI/Managed Bean constructs, and right away deprecated these JSF Managed Beans. In JSF 2.3 one can technically still use the native JSF Managed Beans and DI, but users are strongly encouraged to use the CDI based ones. I intend to remove the native managed beans system fully in JSF 2.3 (if, of course, enough of the other committers agree). So for JAX-RS, let's see how we can practically best approach this. Kind regards, Arjan Tijms

…

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <#569 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AC5XTjfBmF3dM2y8GeM_mWsVu7xO4tYgks5t4Cy4gaJpZM4UVJ2E> .

[jansupol]

Jersey made some experiments in making CDI the primary injection framework, but it was not 100% successful. I do not know the details right now, but Jersey allows for registering additional injectables in runtime, and we had an issue to tell CDI while the application already runs: look cdi, here is another class that from now on you start to inject. So this dynamically added injectables are injected via @context and hk2 and @Inject is handled (more or less) by CDI. Replacing @context with @Inject seems like large refactoring that we prefer to do in 3.0

[arjantijms]

Hi, I'm indeed well aware of Jersey using HK2 internally and the step it took to experiment with CDI there (at Payara I also come into contact with that on almost a daily basis). I've even worked directly with the code I think you're referring to: https://github.com/payara/patched-src-jersey-old/blob/jersey-2.26.payara-maintenance/ext/cdi/jersey-cdi1x/src/main/java/org/glassfish/jersey/ext/cdi1x/internal/ProcessAllAnnotatedTypes.java and https://github.com/payara/patched-src-jersey-old/blob/jersey-2.26.payara-maintenance/ext/cdi/jersey-cdi1x/src/main/java/org/glassfish/jersey/ext/cdi1x/internal/ProcessJAXRSAnnotatedTypes.java#L56 Which is related to org.glassfish.jersey.ext.cdi1x.spi.Hk2CustomBoundTypesProvider being present or not. But these may be orthogonal concerns, in theory at least. At first it's perhaps not so much about replacing the implementation of @context, but just making sure that all artefacts that currently can be injected using @context can be injected using @Inject instead(in so far not already possible), and/or there being CDI alternatives. For instance, in JSF we opted to add a small number of new names for existing native managed bean features, instead of letting CDI take over these in some way. E.g. See https://github.com/eclipse-ee4j/mojarra/blob/master/impl/src/main/java/javax/faces/annotation/ManagedProperty.java which is the CDI replacement for; https://github.com/eclipse-ee4j/mojarra/blob/master/impl/src/main/java/javax/faces/bean/ManagedProperty.java Kind regards, Arjan Tijms

…

On Fri, Jun 1, 2018 at 11:44 AM, jansupol ***@***.***> wrote: Jersey made some experiments in making CDI the primary injection framework, but it was not 100% successful. I do not know the details right now, but Jersey allows for registering additional injectables in runtime, and we had an issue to tell CDI while the application already runs: look cdi, here is another class that from now on you start to inject. So this dynamically added injectables are injected via @context <https://github.com/context> and hk2 and @Inject <https://github.com/Inject> is handled (more or less) by CDI. Replacing @context <https://github.com/context> with @Inject <https://github.com/Inject> seems like large refactoring that we prefer to do in 3.0 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#569 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AC5XTnKa41uVfHIjvkt5CskG8TdU_iH0ks5t4Q0DgaJpZM4UVJ2E> .

[spericas]

As I stated in the PR, @Inject and @context have different targets. @Inject cannot be used for params and @context cannot be used in constructors. A very popular use case for @context is indeed in param position.

The majority of JAX-RS resource methods use @context in param position, except for the entity. This would need to be converted to an @Inject at method level, but would make things less clear regarding the entity param. There's also the issue of ContextResolver's which are somewhat similar to CDI producers and would need tweaking.

Again, the idea of replacing JAX-RS's DI framework with CDI is very sound, but I still think this is an all-or-nothing exercise that will necessarily break backward compatibility, and as such should be out of scope for 2.2.

[chkal]

@spericas To be honest, I'm surprised to hear that using @Context on parameters is a popular choice. I actually never saw this in any JAX-RS code. Of course @*Param usually is used on parameters. But if you want to get UriInfo and friends, using fields usually makes more sense. Or am I missing something here?

[spericas]

@chkal You're right, in thinking about using @Inject at method level (as it cannot be used at param level), I was thinking about @context and @*Param together. Clearly, @*Param is far more popular at that level. Having said that, @context isn't that uncommon in param position.

If it is just about field injection, then it shouldn't be that different. Differences in annotations would be in constructors (@context again here), resource methods and perhaps even in properties.