JAX-RS resources CDI injection does not work if the JAX-RS annotations are located in the implemented interface.

[dgeissl]

Describe the bug
We're using swagger to create interfaces for our rest services. These interfaces already contain all necessary JAX-RS annotations, that's why the implementation classes do not need/want to repeat them.

If such a REST service now tries CDI Injection of EJBs or other beans, the injection does not work and the property is still null when the service is called. The registration as REST service did complete successfully as we can see it being called.

The issue started when we where switching from javaee-7.0 to jakartaee-10.0.

Steps to Reproduce

Use the jakartaee-10.0 feature in openliberty.
Create an Interface & JAXRS service:

import jakarta.ws.rs.*;
@Path("/clock")
public interface ClockService  {
    @GET @Path("/now") @Produces({ "application/json" })
    public Response getTimestamp();
}
---
import jakarta.ws.rs.*;
import jakarta.inject.Inject;

public class ClockServiceIml implements ClockService {
    @Inject
    private TimeService timeService;

    public Response getTimestamp(){ 
        return Response.ok(timeService.getTime());
    }
}

Variations:

• We tried to inject @Stateless session beans and @Named CDI beans, the result was always null
• Repeating the @Path annotation from the Interface in the implementation class this resolve the issue (however this would introduce duplicates between the swagger file and the code which can easily cause conflicts and hard to track bugs)

@Path("/clock") // injected service is no longer null
public class ClockServiceIml implements ClockService {

• making the JAXR-RS resource a @Stateless session bean resolved the injection issue too, at the cost of having to now make all jars an EJB module.

@Stateless // injected service is no longer null
public class ClockServiceIml implements ClockService {

• Specifically marking the JAX-RS resource with @Named still resulted in NPE.

@Named // still NPE on the injected service
public class ClockServiceIml implements ClockService {

Expected behavior
The TimeService should be injected and I can call methods on it.

Diagnostic information:

• OpenLiberty Version: 26.0.0.2
• Affected feature(s) jakartaee-10.0
• Java Version: openj9-17

Additional context
OpenLiberties documentation https://openliberty.io/docs/latest/jaxrs-integration-cdi.html on JaxRs and CDI does not show any evidence as to why this should not work.

[WhiteCat22]

Hi, this looks related to #31493 which went into 26.0.0.1, so likely there is still some work to do. We will investigate this issue.

EDIT: Just to add on for more information, we switched JAX-RS implementations between EE8 and EE9, so our underlying implementation is different between EE7 and EE10.

[dgeissl]

Yes we've seen resteasy stacktraces where formerly there where cxf ones, so we'd assume that.

However we found another woraround:

@RequestScoped // now injection also works
public class ClockServiceIml implements ClockService {

depending on the effort of restructuring the deployment this might be less intrusive and should reflect the previous default anyways.

[visakh005hyu]

Can you please confirm whether, in your implementation, you relied on the JAX‑RS runtime to inherit the class‑level @Path annotation from the interface, and only added @RequestScoped on the implementation class - without adding a @Path annotation to the implementation itself - to expose ClockServiceImpl as a REST resource and have CDI injection working?

[visakh005hyu]

Similar to below one :

import jakarta.ws.rs.*;
@Path("/clock")
public interface ClockService  {
    @GET @Path("/now") @Produces({ "application/json" })
    public Response getTimestamp();
}

import jakarta.ws.rs.*;
import jakarta.inject.Inject;

@RequestScoped 
public class ClockServiceIml implements ClockService {
    @Inject
    private TimeService timeService;

    public Response getTimestamp(){ 
        return Response.ok(timeService.getTime());
    }
}

[visakh005hyu]

Note :

1. The implementation class is not recognized as a JAX‑RS root resource unless it declares its own class‑level @Path.
2. This is why CDI injection (e.g., EJBs or other beans) fails, because the instance is not created by CDI.
3. Adding @RequestScoped makes CDI manage the implementation class, so injection works, but it still does not register the class as a REST resource unless a class‑level @Path is present.

However, We are still investigate on issue. Thanks!!

[dgeissl]

@visakh005hyu the class is recognized as a JAX-RS resource (even if there's no annotation on the implementation class at all), otherwise the endpoint would not be reachable. Only the injection does not work and therefor produces a NPE.

[visakh005hyu]

It seems odd to me. In Jakarta EE 9+, class‑level REST annotations are not inherited from interfaces, only method‑level annotations are, But that does not make the implementation class a JAX‑RS resource.

So I’m curious: which endpoint are you actually using to access the REST resource?

I’m assuming it would be something like ?:

http://localhost:9080/now or http://localhost:9080/clock/now

[dgeissl]

Maybe it's due to us not relying on autodiscovery.
Usually our REST services are implemented in a separate jar file and have to be named in the Applications getClasses. It seems that we just do this in general - even where it's not necessary.

@ApplicationPath("/")
public class JAXRSConfiguration extends Application {

    @Override
    public Set<Class<?>> getClasses() {
        final Set<Class<?>> resources = new HashSet<>();
        resources.add(ClockServiceIml.class);

        return resources;
    }
}

and yes the path is basically http://localhost:9080/clock/now

[visakh005hyu]

It appears that registering a class in Application#getClasses() explicitly tells the runtime which classes should be evaluated as potential JAX‑RS resources. When RESTEasy processes this list, it inspects each registered class and only then does it also look at the interfaces implemented by that class for JAX‑RS annotations. This interface‑level inspection does not occur unless the concrete implementation class is first registered.

Without explicitly including the implementation class in getClasses(), the runtime would never consider it during resource discovery, and any @Path annotation placed on the interface would effectively be ignored. That explains why your CDI injection did not work, RESTEasy was resolving the resource based solely on the implementation class’s @Path annotation.

The code you shared was helpful in reproducing and understanding the issue. It looks like this crucial part was missing from the Steps to Reproduce section.

Since you are explicitly registering classes in Application#getClasses(), and presumably plan to do this for all implementation classes, you will still need to use @RequestScoped for CDI to manage the lifecycle of these resources. Thanks!