Re: [rest-dev] [External] : Re: Jakarta Rest 3.2?

[Jan Supol <jan.supol@xxxxxxxxxx>]

 

Are you suggesting: 

• need to support @Inject by the 3.1 injection wherever the deprecated @Context would be replaced by @Inject 
  

I'm not a CDI expert, but I think this should be doable. My implementation idea was to treat the ContextResolver's as CDI producers. 

I do not think CDI allows for injecting of parametrized beans. ContextResolver's injection should be deprecated. But we have a method on Providers to get the parametrized ContextResolver, and that's fine.

• in JBoss (or any application server), you won't be able to use both injection modules at the same time, so only the deprecated injection will be included (to keep the backward compatibility)

There is a good chance I'm missing something here, but we already do this so I'm not sure how it will be a problem. Where I can see it being an issue is with constructor and method injection. However, we could have a hard rule along the lines of "Your resource or provider must use either use CDI injection for methods and constructors or use the deprecated @Context injection for methods and constructors". 

I'd expect you to be doing the similar things we do in Jersey, i.e. having your own injection framework and having CDI proxies into your injection framework for the RestEasy beans. But having this CDI proxy bean is quite a different thing from having the real CDI beans for pure CDI injection only. In other words, you cannot have on classpath one ReastEasy module that creates an injection bean for let's say @Context Configuration and another module for creating a real CDI bean for @Inject Configuration. 

The hard rule you mentioned still won't be enough, for instance, if there is a provider with @ApplicationScoped, it will be registered by the 3.1 injection as well as by the new CDI injection and the provider would be twice in CDI.

• hence the CDI injection won't be testable by the tck running atop the application server

Or are you suggesting:

•  teach CDI to understand the @Context and have CDI as the main injection framework

This is something I've thought about looking at TBH. Though that's an implementation detail. I know it's possible to do as this is what Quarkus does. 

Quarkus possibly does this with Weld, but with pure CDI, it won't be possible, IMO. So, the Spec should not expect that, and neither should the TCK tests.

 

One obvious catch to all of this is the client side. That said, we've got this issue whether we do a 3.2 or a 4.0. Client side injection is just not going to work without a CDI container.

Thank you for mentioning the Client. The client should not support the injection in CDI, IMO. In theory, you could have infinite clients, that is infinite number of Configuration beans that could be injected into the clients. It is not possible to use a finite number of qualifiers to distinct infinite number of client beans, not mentioning the server side Configuration bean being in the same CDI container.

It is implementable with a high effort and Weld, but the question is whether this messing up with Weld should be enforced by the Spec if CDI is not enough for it.