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.
After thinking more clearly on this, I actually see no reason to make a ContextResolver a CDI producer :) With exception of the required objects for @Context injection, which are easily done with a CDI producer, the lookup for other contexts is done with the Provider interface, e.g. Provider.getContextResolver(). I apologize for adding unneeded confusion here. I really should have thought about this more.
-
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.
In RESTEasy we kind of hack CDI to be honest. I don't love it, but it works. You can already mix using @Context and @Inject into a resource. Granted, it would be a lot nicer to say "CDI only beans" and we could remove a bunch of cruft, but it works.
That said, I realize this needs to work in other implementations as well. If that's not possible or doesn't make sense, I completely understand and maybe it's not a viable solution at all.
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.
I thought this was already required to happen to be honest. Maybe I'm misinterpreting this though.
I read that as a provider must be @ApplicationScoped if an scope defining annotation is not already defined. In other words, from my understanding, a provider can already be injected with @Inject or
@Context.
-
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.
This definitely could be true. I honestly don't know it well enough :)
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.
IMO we could just say something like "CDI will not work with clients not running inside a container that does not support CDI". I definitely agree we should not tie any of this to any CDI implementation.
