4 Replies Latest reply on Apr 2, 2013 7:17 AM by jrantav

    inconsistent JNDI names for EJBs

    jrantav Novice

      I have a stateless session bean like this:

       

      @Stateless(name="ProcessService")

      @LocalBean

      public class ProcessServiceEJB implements ProcessService {

       

      that gets bound to:

       

              java:global/manageclinic-service-process-app/ProcessService

              java:app/manageclinic-service-process-app/ProcessService

              java:module/ProcessService

       

       

      and I have another stateless session bean:

       

      @Stateless(name="ManageClinicService")

      @LocalBean

      public class ManageClinicServiceEJB implements ManageClinicService {

       

      which gets bound to:

       

              java:global/manageclinic-service-manageclinic-app/ManageClinicService!complete.path.to.service.interface.ManageClinicService

              java:app/manageclinic-service-manageclinic-app/ManageClinicService!complete.path.to.service.interface.ManageClinicService

              java:module/ManageClinicService!complete.path.to.service.interface.ManageClinicService

             

      why the difference? I can't see any reason why JNDI names are different. What controls if interface class is used in a JNDI name?

        • 1. Re: inconsistent JNDI names for EJBs
          jaikiran pai Master

          Are those the complete set of JNDI names? I think it's missing a few more of the expected JNDI names. As for the rules - it's defined in the EJB 3.1 spec on what the JNDI names are going to be.

          • 2. Re: inconsistent JNDI names for EJBs
            jaikiran pai Master

            What do the ManageClinicService and ProcessService interfaces look like?

            1 of 1 people found this helpful
            • 3. Re: inconsistent JNDI names for EJBs
              jrantav Novice

              Complete sets of JNDI names reported are:

               

              13:42:17,361 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-10) JNDI bindings for session bean named ManageClinicService in deployment unit deployment "manageclinic-service-manageclinic-app.war" are as follows:

               

                      java:global/manageclinic-service-manageclinic-app/ManageClinicService!complete.path.to.ejb.impl.ManageClinicServiceEJB

                      java:app/manageclinic-service-manageclinic-app/ManageClinicService!complete.path.to.ejb.impl.ManageClinicServiceEJB

                      java:module/ManageClinicService!complete.path.to.ejb.impl.ManageClinicServiceEJB

                      java:global/manageclinic-service-manageclinic-app/ManageClinicService!complete.path.to.service.interface.ManageClinicService

                      java:app/manageclinic-service-manageclinic-app/ManageClinicService!complete.path.to.service.interface.ManageClinicService

                      java:module/ManageClinicService!complete.path.to.service.interface.ManageClinicService

               

              13:42:17,361 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-16) JNDI bindings for session bean named ProcessService in deployment unit deployment "manageclinic-service-process-app.war" are as follows:

               

                      java:global/manageclinic-service-process-app/ProcessService!complete.path.to.ejb.impl.ProcessServiceEJB

                      java:app/manageclinic-service-process-app/ProcessService!complete.path.to.ejb.impl.ProcessServiceEJB

                      java:module/ProcessService!complete.path.to.ejb.impl.ProcessServiceEJB

                      java:global/manageclinic-service-process-app/ProcessService

                      java:app/manageclinic-service-process-app/ProcessService

                      java:module/ProcessService

              • 4. Re: inconsistent JNDI names for EJBs
                jrantav Novice

                Ah, silly me. The ManageClinicService interface had annotation @Local to signal local business interface, whereas the ProcessService interface had no annotation at all. Both seemed to work equally well.