1 Reply Latest reply on Jan 28, 2016 10:57 PM by jaikiran pai

    Conflict when using @EJB and @Schedule

    Marco Strauch Newbie

      Hi,

       

      I have a singleton session bean with a method annoated with @Schedule to create an inverval timer. When I try to access the session bean using annotation @EJB this fails with follow message:

       

       

      Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYEJB0408: More than one EJB found with interface of type 'marabu.pegasos.server.scheduler.core.spi.ISchedulerServiceLocal' for binding marabu.pegasos.server.scheduler.core.services

      .ServerProcessExtServiceBean/schedulerService. Found: [View of type marabu.pegasos.server.scheduler.core.spi.ISchedulerServiceLocal for org.jboss.as.ejb3.component.singleton.SingletonComponentDescription{serviceName=service jboss.deployment.subunit."pos.ear"."

      pos-scheduler.jar".component.SchedulerServiceManagementBean}@5133e79b, View of type marabu.pegasos.server.scheduler.core.spi.ISchedulerServiceLocal for org.jboss.as.ejb3.component.singleton.SingletonComponentDescription{serviceName=service jboss.deployment.sub

      unit."pos.ear"."pos-scheduler.jar".component.SchedulerServiceBean}@5e4a2c3e]

              at org.jboss.as.ejb3.deployment.processors.EjbInjectionSource.getResourceValue(EjbInjectionSource.java:90)

              at org.jboss.as.ee.component.deployers.ComponentInstallProcessor.processBindings(ComponentInstallProcessor.java:263)

              at org.jboss.as.ee.component.deployers.ComponentInstallProcessor.access$000(ComponentInstallProcessor.java:80)

              at org.jboss.as.ee.component.deployers.ComponentInstallProcessor$1.handle(ComponentInstallProcessor.java:215)

              at org.jboss.as.ee.component.ClassDescriptionTraversal.run(ClassDescriptionTraversal.java:54)

              at org.jboss.as.ee.component.deployers.ComponentInstallProcessor.deployComponent(ComponentInstallProcessor.java:218)

              at org.jboss.as.ee.component.deployers.ComponentInstallProcessor.deploy(ComponentInstallProcessor.java:101)

       

       

      The reason maybe that the session bean was populated with an additional view for the schedule annotation. The Bean deployment info shows this:

       

      06:32:35,450 INFO  [org.jboss.as.ejb3.deployment] (MSC service thread 1-1) WFLYEJB0473: JNDI bindings for session bean named 'SchedulerServiceManagementBean' in deployment unit 'subdeployment "pos-scheduler.jar" of deployment "pos.ear"' are as follows:

       

              java:global/pos/Scheduler/SchedulerServiceManagementBean!marabu.pegasos.server.scheduler.core.spi.ISchedulerServiceLocal

              java:app/Scheduler/SchedulerServiceManagementBean!marabu.pegasos.server.scheduler.core.spi.ISchedulerServiceLocal

              java:module/SchedulerServiceManagementBean!marabu.pegasos.server.scheduler.core.spi.ISchedulerServiceLocal

             java:global/pos/Scheduler/SchedulerServiceManagementBean

              java:app/Scheduler/SchedulerServiceManagementBean

              java:module/SchedulerServiceManagementBean

       

      The bold lines are added when I add the method with the @Schedule annotation.

       

      I think a solution would be to use the mappedName attribute within the @EJB annotation but I think this is an error. Because from client side I should not need to know something about the bean internals, or not?

       

      Kind regards,

       

      Marco.

        • 1. Re: Conflict when using @EJB and @Schedule
          jaikiran pai Master

          Marco Strauch wrote:

           

          Hi,

           


          I think a solution would be to use the mappedName attribute within the @EJB annotation but I think this is an error. Because from client side I should not need to know something about the bean internals, or not?

           

          You don't need to use mappedName attribute. Instead use the beanName attribute of @EJB where you can specify the name of the bean (one among the many beans which expose that business interface) which you want to inject. This approach is spec compliant and portable.