Hello All,In section
11.2.3[1] 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 [2]) and a
PR [3] to make the @Path, @Provider and @ApplicationPath annotations be bean defining annotations. This does create a different potential issue for applications.
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 and I have discussed a bit, but we'd like to see what others think as well.