Re: [rest-dev] [External] : Deprecating @Context and Supporting CDI

[James Perkins <jperkins@xxxxxxxxxx>]

Yes, sorry not sure why I was thinking of a qualifier, but yes we could treat it like @Inject. Where it could be an issue is parameter arguments.

James R. Perkins

Principal Software Engineer

Red Hat

On Thu, Mar 27, 2025 at 6:33 AM Arjan Tijms <arjan.tijms@xxxxxxxxxxx> wrote:

Hi,

> I agree on making the transition smooth. We could potentially I guess make @Context a qualifier, but I'm not sure otherwise how we'd get it to work

CDI extensions can also just interpret @Context, without the need to make it a qualifier. This is basically how I map EJB annotations to other things in Jakarta in our OmniBeans project:

https://github.com/OmniFish-EE/omni-beans/blob/develop/impl/src/main/java/ee/omnifish/omnibeans/CdiExtension.java#L70

Kind regards,

Arjan Tijms

On Wed, 26 Mar 2025 at 18:46, James Perkins via rest-dev <rest-dev@xxxxxxxxxxx> wrote:

James R. Perkins

Principal Software Engineer

Red Hat

On Tue, Mar 25, 2025 at 10:27 AM Santiago Pericasgeertsen <santiago.pericasgeertsen@xxxxxxxxxx> wrote:

Hi,

 Thanks for starting this James, I agree we need to get this going.

 Inlined ...

I'd like to propose we make an attempt to resolve the issue of deprecating @Context and supporting CDI.

 +1

We currently have the following issues associated with this:

• https://github.com/jakartaee/rest/issues/569
• https://github.com/jakartaee/rest/issues/749
• https://github.com/jakartaee/rest/issues/951
• https://github.com/jakartaee/rest/issues/952
• https://github.com/jakartaee/rest/issues/953
• https://github.com/jakartaee/rest/issues/1137
• https://github.com/jakartaee/rest/issues/1155
• https://github.com/jakartaee/rest/issues/1195
• https://github.com/jakartaee/rest/issues/1206
• https://github.com/jakartaee/rest/issues/1209
• https://github.com/jakartaee/rest/issues/1214
• https://github.com/jakartaee/rest/issues/1215

 I see a number of these are still unassigned. It would be nice if contributors could go over the list and pick up at least one.

My proposal is that we add @Deprecated(forRemoval = true) to the @Context annotation. We should probably also deprecate the ContextResolver as that can be replaced by a CDI producer.

 I suspect we have agreement on this. +1 for me.

For the client, I think we should just be explicit in the specification that if a client is running within a CDI container, that CDI will be supported.

 Yes, it must be supported. 

If it's outside a CDI container, it will not be.

 Correct.

The question there becomes, how do we support injection for resources which @Context injection previously worked on. We could just say, it no longer supports it and you need to boot a CDI container if you want that. Or, potentially, there is a way to say we support Jakarta Injection and allow @Inject to effectively replace @Context.

 We should make the transition as smooth as possible, if we can support @Context via CDI, it would be a better option IMO. However, I’d like to hear from those actually implementing the spec on this one.

I agree on making the transition smooth. We could potentially I guess make @Context a qualifier, but I'm not sure otherwise how we'd get it to work. Next week I will try to look at how this could be done in RESTEasy.

Currently RESTEasy does allow for field injection of all the types @Context works with. It doesn't yet work for method parameters or constructor parameters well, but that is something I will shift some focus to.

 

— Santiago

_______________________________________________
rest-dev mailing list
rest-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org