5 Replies Latest reply on Jul 16, 2019 9:33 AM by Jaikiran Pai

    Unable to do JNDI lookup a stateful session bean on JBOSS EAP 7.1

    Aman Painuly Newbie

      I am currently working on an application where I use EJB3.2 to write the business logic. The application is running on jboss EAP7.1 The client is unable to lookup remote stateful bean.

      Below is outline of the structure of the project:

      Gems -- 
              |-- Gems-ejb (project containing the EJB code)
              |
              |---Gems-service (project containing the client and the rest services)

      Here are things I have already done:

      1. Added application user in the server
      2. Created session bean (Gems-ejb):
        1. @Stateful
          @Remote(ActCounterpartUploadBeanRemote.class)
          public class ActCounterpartUploadBean implements ActCounterpartUploadBeanRemote {
            public int getId_counterpartIndex() {
            return id_counterpartIndex;
            }
          }
      3. Created interface for the session bean (Gems-ejb):
        1. public interface ActCounterpartUploadBeanRemote {
            public int getId_counterpartIndex();
          }
      4. Created client (Gems-service-->src --> main --> java):
        1. public class DataSubmissionUtil {
            private static Context initialContext=getInitialContext();
            private static Context getInitialContext() {
            try {
            if(initialContext == null) {
            final Hashtable<String, String> jndiProperties = new Hashtable<>();
            jndiProperties.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.naming.client.WildFlyInitialContextFactory");
          jndiProperties.put(Context.PROVIDER_URL,"remote+http://localhost:8080");
            initialContext = new InitialContext(jndiProperties);
            }
            }
            catch (NamingException ne) {
            ne.printStackTrace();
            }
            return initialContext;
            }

            ActCounterpartUploadBeanRemote objActCtpUploadBean = lookupActCounterpartUploadBeanRemote();
            public ActCounterpartUploadBeanRemote lookupActCounterpartUploadBeanRemote() {
            try {
            final String appName = "";
            final String moduleName = "Gems-ejb-3.0-SNAPSHOT"; //the jar that is created for Gems-ejb on building the project
            final String beanName = ActCounterpartUploadBean.class.getSimpleName();
            final String viewClassName = ActCounterpartUploadBeanRemote.class.getName();
            context.lookup("ejb:" + moduleName + "/" + beanName + "!" + viewClassName + "?stateful");
            return (ActCounterpartUploadBeanRemote) initialContext.lookup("ejb:" + appName + "/" + moduleName + "/" + distinctName + "/" + beanName + "!" + viewClassName + "?stateful");
            }
            catch (NamingException ne) {
            throw new RuntimeException(ne);
            }
            }
          }
      5. Added wildfly-config.xml ( Gems-service -->src --> main --> resources):
        1. <configuration>
            <authentication-client xmlns="urn:elytron:1.0">
            <authentication-rules>
            <rule use-configuration="default" />
            </authentication-rules>
            <authentication-configurations>
            <configuration name="default">
            <sasl-mechanism-selector selector="#ALL" />
            <set-mechanism-properties>
            <property key="wildfly.sasl.local-user.quiet-auth" value="true" />
            </set-mechanism-properties>
            <providers>
            <use-service-loader/>
            </providers>
            </configuration>
            </authentication-configurations>
            </authentication-client>
          </configuration>

      On starting the server the logs shows following JNDI bindings:

      JNDI bindings for session bean named 'ActCounterpartUploadBean' in deployment unit 'deployment "Gems-service.war"' are as follows:  
      java:global/Gems-service/ActCounterpartUploadBean!org.maks.gems.actions.ActCounterpartUploadBeanRemote
      java:app/Gems-service/ActCounterpartUploadBean!org.maks.gems.actions.ActCounterpartUploadBeanRemote
      java:module/ActCounterpartUploadBean!org.maks.gems.actions.ActCounterpartUploadBeanLocal
      java:jboss/exported/Gems-service/ActCounterpartUploadBean!org.maks.gems.actions.ActCounterpartUploadBeanRemote
      java:global/Gems-service/ActCounterpartUploadBean
      java:app/Gems-service/ActCounterpartUploadBean
      java:module/ActCounterpartUploadBean

      I expected the code to run fine however, I get following error:

      Failed to look up "/Gems-ejb-3.0-SNAPSHOT//ActCounterpartUploadBean!org.maks.gems.actions.ActCounterpartUploadBeanRemote?stateful" [Root exception is org.jboss.ejb.client.RequestSendFailedException: EJBCLIENT000409: No more destinations are available] 
        • 1. Re: Unable to do JNDI lookup a stateful session bean on JBOSS EAP 7.1
          Jaikiran Pai Master

          Can you paste the complete exception stacktrace? It looks like you are invoking this EJB from a standalone Java client, is that right?

          • 2. Re: Unable to do JNDI lookup a stateful session bean on JBOSS EAP 7.1
            Aman Painuly Newbie

            Hi Jaikiran,

            I have recently started working on JBoss and EJB so I do not understand what you meant by standalone Java client.

             

            I was able to fix the issue, as the JNDI lookup string I was using was incorrect. I changed it to :

            context.lookup("/Gems-service/ActCounterpartUploadBean!org.maks.gems.actions.ActCounterpartUploadBeanLocal");

            and now my client is able to lookup for the bean.

             

            However, I am still unable to lookup for stateful bean and get the same error if I try with:

            context.lookup("/Gems-service/ActCounterpartUploadBean!org.maks.gems.actions.ActCounterpartUploadBeanLocal?stateful");

             

            When I try with stateful, I get the same exception.

            Can you please guide me where could I be going wrong.

             

            Regards,

            Aman

            • 3. Re: Unable to do JNDI lookup a stateful session bean on JBOSS EAP 7.1
              Jaikiran Pai Master

              aman.painuly  wrote:

               

              Hi Jaikiran,

              I have recently started working on JBoss and EJB so I do not understand what you meant by standalone Java client.

               

              I meant a client which isn't running within the JVM of the (WildFly) server itself.

               

              aman.painuly  wrote:

               


               

              I was able to fix the issue, as the JNDI lookup string I was using was incorrect. I changed it to :

              context.lookup("/Gems-service/ActCounterpartUploadBean!org.maks.gems.actions.ActCounterpartUploadBeanLocal");

              and now my client is able to lookup for the bean.

               

              However, I am still unable to lookup for stateful bean and get the same error if I try with:

              context.lookup("/Gems-service/ActCounterpartUploadBean!org.maks.gems.actions.ActCounterpartUploadBeanLocal?stateful");

               

              When I try with stateful, I get the same exception.

              Can you please guide me where could I be going wrong.

               

              Regards,

              Aman

              There are quickstart examples to get you started with these examples. You can find them here GitHub - wildfly/quickstart: Holds all versioned WildFly quickstarts . Take a look at the quickstart/ejb-remote at master · wildfly/quickstart · GitHub  one for this specific example.

              • 4. Re: Unable to do JNDI lookup a stateful session bean on JBOSS EAP 7.1
                Aman Painuly Newbie

                Hi Jaikiran,

                 

                I am using maven to generate ejb.jar which is included as dependency in the web-service.war. It is then deployed on the EAP server. Hence I guess, the application is running within the jvm of server

                However, I am still unable to do the EJB bean lookup from the client (in this case, as REST-web-service) after adding "?stateful" in the look up string.

                I assume, this results in returning a new object when I invokes bean marked @stateful every time i do jndi lookup from different web-services.

                 

                Regarding the quickstart example, u mentioned, I have, in fact, used the same sample application as reference to implement ejb bean invocation from the web-service client.

                • 5. Re: Unable to do JNDI lookup a stateful session bean on JBOSS EAP 7.1
                  Jaikiran Pai Master

                  aman.painuly  wrote:

                   

                  Hi Jaikiran,

                   

                  I am using maven to generate ejb.jar which is included as dependency in the web-service.war. It is then deployed on the EAP server. Hence I guess, the application is running within the jvm of server

                  However, I am still unable to do the EJB bean lookup from the client (in this case, as REST-web-service) after adding "?stateful" in the look up string.

                  I assume, this results in returning a new object when I invokes bean marked @stateful every time i do jndi lookup from different web-services.

                   

                  Regarding the quickstart example, u mentioned, I have, in fact, used the same sample application as reference to implement ejb bean invocation from the web-service client.

                  Given that it's part of the same (.ear) application, you can just use the "java:app/...."  JNDI name that you see in the server log file. Something like:

                  new InitialContext("java:app/Gems-service/ActCounterpartUploadBean!org.maks.gems.actions.ActCounterpartUploadBeanRemote");

                   

                  If the EJB .jar and .war are deployed independently, you can just use the "java:global/..." JNDI name that's displayed in the server log file.