search

jakartaee / rest

Jakarta RESTful Web Services
Other
351 stars 114 forks source link

Result of Application methods for CDI beans #1215

Open jansupol opened 4 months ago

jansupol commented 4 months ago

Application getClasses() and getSingletons() return the classes and instances used by the application. Should they not be registered, they would not be used by the application.

However, in the CDI, should the providers be CDI beans, no matter whether they are registered or not, they are known to CDI. Hence, getting all providers from CDI will include them.

The questions:

  1. Should the CDI bean providers be included just when registered in the Application? Or is it ok to have the provider be a bean and it no longer needs to be registered (using the META-INF/services/jakarta.ws.rs.core.Feature for instance)?
  2. If so, does it matter that the behaviour could be potentially different in the CDI-managed environment and non-cdi env using the non-cdi injection?
jamezp commented 4 months ago

This is a good question and is relevant to both 3.2 and 4.0.

The Application.getSingletons() is deprecated which helps us out a bit. We can't really use CDI for anything returned from this method as it returns already instantiated objects.

For Application.getClasses(), I think those should be usable in that you could use the BeanManager to lookup those types.

With regards to the service loading, that's a great question. Without creating some kind of custom ServiceLoader which returns only class types, there really isn't a good way to make those providers a CDI bean. Therefore, IMO, we should state anything loaded from a service loader will not work with CDI. Not sure on the exact wording we should use though.

That said, from an implementation point of view, I could see creating a service loader which registers those as CDI beans in an CDI extension.