Re: CDI integration

Guillermo González de Agüero


I've checked it and adding a new bean with CDI 2.0 is just as simple as creating an extension like this (taken from

public class JaxRsExtension implements Extension {
    public void addClasses(@Observes BeforeBeanDiscovery bbd) {
        bbd.addAnnotatedType(RestResource.class, RestResource.class.getName()).

The only caveat is that the implementation will need to know the classes by that point, which is before ServletContainerInitializer is fired (I'm not sure that's a problem; just stating so implementers may comment on it). That prevents the hard dependency on CDI, making everyone happy.



Guillermo González de Agüero

On Fri, Jun 2, 2017 at 5:32 PM, Pavel Bucek <pavel.bucek@...> wrote:

consider this as a subthread :)

On 02/06/2017 16:27, Guillermo González de Agüero wrote:

Ad @Stereotype - I'd need to check whether we can easily do that, since it would create a dependency on javax.enterprise.inject. I don't understand the remark about that annotation not being there in the runtime - it will be there, it has retention runtime (otherwise it wouldn't work)

I meant CDI will only be needed at (JAX-RS implementation) compile time. Applications won't need it as annotations not present on the classpath are just erased at runtime. So people using Spring or wathever non-CDI framework won't see any difference. Hope it clearer now?

To be absolutely honest, I'd expect CNFE or something like that. I already wrote a test, which corresponds to what you wrote ;) So thanks for that info, I wasn't aware of this behavior.

There is a little (forward) issue with this - similarly to any other "optional" dependency, there will be issues with this when Java 9 modules are used. Once the dependency on CDI API is declared in JAX-RS API module-info, CDI API will be required on the module path of any JAX-RS enabled app/code (at least for compilation).

Not saying that is a deal breaker, it's just something we need to consider.


Join to automatically receive all group messages.