2
votes

I have a class like this:

@Singleton
@Startup
@Default
public class A {

    private Manager manager; // Manager is an interface

    @PostConstruct
    public void init() {
      if (some rule is true) {
         manager = new ManagerA();
      } else {
         manager = new ManagerB();
      }
    }

    public Manager getManager() {
       return manager;
    }

}

Now I have a endpoint JAX-RS like this:

@Path("mypath")
public class B {

    // @Inject vs @Resource vs @EJB - my doubt
    private A objA;

    @POST
    @Path("resource")
    @Consumes("application/json")
    @Produces("application/json")
    public Response myMethod(String param) {

        objA.getMamager().executeSomeMethod(param);

        return Response.status(HttpStatus.SC_OK).build();
    }
}

When I go inject the object it takes errors regardless of the annotation that I use. Some errors:

  • WFLYWELD0044: Error injecting resource into CDI managed bean. Can't find a resource named

  • Failed to start service Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type A with qualifiers @Default

How to solve it?

1
If you are using @Inject (which I would suggest), then the discovery of beans is dependant on whenther you have beans.xml and what bean discovery mode you have. If it is wrongly set up, you end up with what you saw - WELD-001408: Unsatisfied dependencies.... In short that means no such bean A was found with qualifiers @Default. Try adding empty beans.xml into your application and also mark your A bean as @ApplicationScoped (keep it @Singleton and @Startup as well). HAving the @Default qualifier there is redundant, you can remove it (it is assumed by defauft).Siliarus

1 Answers

1
votes

you probably have a race condition with your @Singleton @Startup bean and something it depends on. i've seen this several times myself. especially when the @Startup bean depends on another facility that the container has to initialize (q.v. JPA, JMS, CDI, etc.). if this is the case, remove the @Startup and just let the bean get initialized when it gets first injected into a dependent.

if you really, really, really need the bean to be @Startup, try to isolate what dependency it is failing on, and mark that dependency in the @DependsOn(depends="blah blah blah") annotation.

another workaround i have used, if you cannot remove the @Startup, isolate the dependency and lazy inject it via JNDI (old school). sometimes, all the bells and whistles just get in the way of "how it's really done." /grin

caveat emptor