[wildfly-dev] Re: RESTEasy and CDI in Deployments

Thanks for the write-up James. I'll just add a few random thoughts for people to chew on. 1) From CDI perspective, I think the linked PR (turning annotation to bean defining) makes most sense; at least that's where we landed after some discussion. There are other ways but they are hacky and prone to errors. For instance explicitly registering all classes as beans via extensions but then you have to resolve conflicts when jaxrs annotated class also defines, for example, cdi scope and gets picked up twice. 2) This approach won't solve everything of course. An example of potential problem is when you have an archive with CDI extension and without beans.xml, in such case, RE will fail to discover their classes and register them as beans because such archive is by definition not a bean archive (see https://jakarta.ee/specifications/cdi/2.0/cdi-spec-2.0.html#bean_archive). This, however, is easily fixable by adding beans.xml into the JAR on user side. But this scenario wouldn't work even today, the jaxrs classes wouldn't be recognized as beans. And from CDI point of view, this is actually correct anyway. 3) Jaxrs spec doesn't go too deep WRT CDI integration, for instance it completely 'forgets' to mention that classes with their annotations should be subject to CDI proxyability rules. I.e. you can encounter a final class with @Path annotation that the spec expects to be treated as CDI bean, but you cannot proxy final classes so this is invalid according to CDI spec. This is the problem from WFLY-2859, but IMO it is basically a contradiction in the jaxrs specification. There might be other similar surprises but I am not expert on jaxrs specification :) 4) CDI has no standardized API for registering additional bean defining annotations as this cannot be done universally across environments. This means the jaxrs spec cannot simply add this is a requirement. Matej On Tue, Jul 5, 2022 at 10:44 PM James Perkins <jperkins(a)redhat.com&gt; wrote: