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

James, do we need to get this sorted for WF 27 Beta1?

On Mon, Jul 11, 2022 at 5:47 AM Matej Novotny <manovotn(a)redhat.com&gt; wrote: > 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 :) > Me neither. Without reading beyond this thread, the sentence '*In a product that supports CDI, implementations MUST support the use of CDI-style Beans as root resource classes, providers and Application subclasses' says 'MUST support' *which doesn't rule out non-spec compliant mode that does not have that behavior. So, James, can the jaxrs subsystem provide such an option, defaulting to spec compliant? In terms of impl perhaps WeldCapability could add a method to register bean defining annotations, which TBH is a better approach than hard coding them in weld subsystem classes is.

> 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: > >> Hello All, >> In section 11.2.3 >> <https://jakarta.ee/specifications/restful-ws/3.1/jakarta-restful-ws-spec-... >> of the Jakarta REST Specification it states: >> >> *In a product that supports CDI, implementations MUST support the use of >> CDI-style Beans as root resource classes, providers and Application >> subclasses. Providers and Application subclasses MUST be singletons or use >> application scope.* >> >> This is something we haven't completely done yet in WildFly. It >> currently works for the most part because users generally add a beans.xml >> to their deployment. In previous versions of CDI the default bean discovery >> mode was all. The default is now annotated. With that it seems more >> critical to enable REST resources, providers and applications CDI beans. >> What currently happens now is beans are processed by the >> ResteasyCdiExtension and given scopes. This doesn't quite work the same if >> the bean does not have a bean qualifying annotation and the discovery mode >> is annotated. >> >> I filed an issue (WFLY-16545 >> <https://issues.redhat.com/browse/WFLY-16545> [2]) and a PR >> <https://github.com/wildfly/wildfly/pull/15706> [3] to make >> the @Path, @Provider and @ApplicationPath annotations be bean defining >> annotations. This does create a different potential issue for applications. >> WFLY-2859 <https://issues.redhat.com/browse/WFLY-2859> [4] has one >> potential issue which was raised before and seems to be the reason we do >> not treat these types as bean defining annotations. >> >> I think the REST spec does need some clarification for providers that >> they are required to be CDI compliant. However, given the text from 11.2.3 >> of the spec and the fact that the default discovery mode is now annotated, >> it seems we should make these bean defining annotations. >> >> @Matej Novotny <manovotn(a)redhat.com&gt; and I have discussed a bit, but >> we'd like to see what others think as well. >> >> [1]: >> https://jakarta.ee/specifications/restful-ws/3.1/jakarta-restful-ws-spec-... >> [2]: https://issues.redhat.com/browse/WFLY-16545 >> [3]: https://github.com/wildfly/wildfly/pull/15706 >> [4]: https://issues.redhat.com/browse/WFLY-2859 >> >> -- >> James R. Perkins >> JBoss by Red Hat >> > _______________________________________________ > wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org > To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s -- Brian Stansberry Principal Architect, Red Hat JBoss EAP He/Him/His