1 2 Previous Next 27 Replies Latest reply on Jul 31, 2013 7:13 AM by millsp

    JBoss 7.2 Final (from Git) ... client jar issues ?

    millsp Newbie

      Hi

       

      We've just got the latest 7.2 code from Git, the 7.2 client jar is throwing errors when used without a -Djboss.ejb.client.properties.file.path reference (the test code is setting properties programmatically) :

       

      CPModelClient : main() : ENTER

      01-Mar-2013 14:32:53 org.xnio.Xnio <clinit>

      INFO: XNIO Version 3.0.7.GA

      01-Mar-2013 14:32:53 org.xnio.nio.NioXnio <clinit>

      INFO: XNIO NIO Implementation Version 3.0.7.GA

      01-Mar-2013 14:32:53 org.jboss.remoting3.EndpointImpl <clinit>

      INFO: JBoss Remoting version 3.2.14.GA

      01-Mar-2013 14:32:53 org.jboss.ejb.client.EJBClient <clinit>

      INFO: JBoss EJB Client version 1.0.16.Final

      CPModelClient : main() : ERROR : EJBCLIENT000025: No EJB receiver available for handling [appName:cp-model, moduleName:cp-model.jar, distinctName:] combination for invocation context org.jboss.ejb.client.EJBClientInvocationContext@106caf16

      java.lang.IllegalStateException: EJBCLIENT000025: No EJB receiver available for handling [appName:cp-model, moduleName:cp-model.jar, distinctName:] combination for invocation context org.jboss.ejb.client.EJBClientInvocationContext@106caf16

              at org.jboss.ejb.client.EJBClientContext.requireEJBReceiver(EJBClientContext.java:693)

              at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:116)

              at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183)

              at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:177)

              at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:161)

              at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:124)

              at $Proxy0.create(Unknown Source)

              at com.cedar.cp.model.client.CPModelClientLoop.main(CPModelClientLoop.java:105)

      CPModelClient : main() : EXIT

       

      It works fine when we specify -Djboss.ejb.client.properties.file.path with an appropriate file.  We use EJB client calls extensively in our application, but using a properties file isn't feasible for all our use cases.

       

      Would it be possible to raise this as a bug please, if it isn't already ?  I can supply test code and recreation details on request.

       

      Thanks -

       

      Phil

       

      (See earlier correspondence on https://community.jboss.org/thread/220992)

        • 1. Re: JBoss 7.2 Final (from Git) ... client jar issues ?
          jaikiran pai Master

          I don't fully understand the setup. Do you have a jboss-ejb-client.properties in your classpath? If yes, what does it look like? If no, then the exception would be expected (unless you do programatic EJB client context configuration).

          • 2. Re: JBoss 7.2 Final (from Git) ... client jar issues ?
            millsp Newbie

            Sorry I should have made that clear - yes, the test case either uses the properties file, or configures the context programmatically.

            • 3. Re: JBoss 7.2 Final (from Git) ... client jar issues ?
              jaikiran pai Master

              millsp wrote:

               

              Sorry I should have made that clear - yes, the test case either uses the properties file, or configures the context programmatically.

              So in the case where it is failing, is it trying to configure it programatically? If yes, please post the relevant code.

              • 4. Re: JBoss 7.2 Final (from Git) ... client jar issues ?
                millsp Newbie

                            String url = System.getProperty("url");
                            if( url == null)
                                throw new Exception( "Must specify host:port URL with -Durl=host:port");

                 

                            String usr = System.getProperty("user");
                            if( usr == null)
                                throw new Exception( "Must specify user with -Duser=<user>");

                 

                            String pwd = System.getProperty("password");
                            if( pwd == null)
                                throw new Exception( "Must specify password with -Dpassword=<password>");

                           Properties contextProps = new Properties();

                 

                           contextProps.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory" );
                           contextProps.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");

                 

                //              Define -Dcp.tests to force it to use jboss-ejb-client.properties, which you can optionally specify as :
                //              -Djboss.ejb.client.properties.file.path=D:\\some\\path\\jboss-ejb-client.properties

                           if(System.getProperty("cp.tests") == null)
                                contextProps.put("jboss.naming.client.ejb.context", true);

                 

                            contextProps.put(Context.SECURITY_PRINCIPAL, usr );
                            contextProps.put(Context.SECURITY_CREDENTIALS, pwd );
                            contextProps.put(Context.PROVIDER_URL, "remote://" + url );

                 

                            int n = 0;
                            for( int i=0; i<contextRepeats; i++ )
                            {
                                InitialContext ic = new InitialContext( contextProps );

                                for( int j=0; j<lookupRepeats; j++ )
                                {
                                    CPLoginSessionHome lohome = (CPLoginSessionHome) PortableRemoteObject.narrow(ic.lookup( LOGIN_SLSB_REMOTE_JNDI ), CPLoginSessionHome.class);

                                    // etc.

                 

                It is reliable if I define -Dcp.tests and -Djboss.ejb.client.properties.file.path with a file like this :

                 

                endpoint.name=phil-pc
                remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
                remote.connections=phil-test
                remote.connection.phil-test.host=<my host name>
                remote.connection.phil-test.port=7914
                remote.connection.phil-test.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false

                 

                If I omit -Dcp.tests and -Djboss.ejb.client.properties.file.path, so it is just using the properties that have been set programmatically, I get

                 

                java.lang.IllegalStateException: EJBCLIENT000025: No EJB receiver available for handling [appName:cp-model, moduleName:cp-model.jar, distinctName:] combination for invocation context org.jboss.ejb.client.EJBClientInvocationContext@3d3e58d4CPModelClient : main() : ERROR : null

                 

                with or without a nested NullPointerException.

                 

                We didn't get this error with the 7.1.0 client jar, it seems to have become apparent since then.

                 

                I can supply a test EAR / client code / recreation steps if that is going to be of any help

                 

                Phil

                • 5. Re: JBoss 7.2 Final (from Git) ... client jar issues ?
                  jaikiran pai Master

                  This looks more like an issue with remote-naming than with EJB client project. I remember seeing a similar thread recently. Why are you using remote:// and EJB client API in the same code? Having said that, I don't know why remote-naming is passing along a null connection to the RemotingConnectionEJBRecevier constructor, which is what causes the NPE.

                  • 6. Re: JBoss 7.2 Final (from Git) ... client jar issues ?
                    millsp Newbie

                    > Why are you using remote:// and EJB client API in the same code?

                     

                    To be honest I don't understand the difference.  Initially we just tried to set properties within the code, but ran into resource issues with the 7.1.0 client - using the properties file seemed to work round those and let out unit test suite get further.

                     

                    It's quite possible that what I'm doing doesn't make sense, and I need to do something differently.  The constraint for us is that we need to set the connection up programmatically because we can't always use a properties file.

                    • 7. Re: JBoss 7.2 Final (from Git) ... client jar issues ?
                      jaikiran pai Master

                      millsp wrote:

                       

                      > Why are you using remote:// and EJB client API in the same code?

                       

                      To be honest I don't understand the difference.  Initially we just tried to set properties within the code, but ran into resource issues with the 7.1.0 client - using the properties file seemed to work round those and let out unit test suite get further.

                       

                      See this https://docs.jboss.org/author/display/AS72/Remote+EJB+invocations+via+JNDI+-+EJB+client+API+or+remote-naming+project

                      • 8. Re: JBoss 7.2 Final (from Git) ... client jar issues ?
                        millsp Newbie

                        OK thanks - will review that and check our code.

                        • 9. Re: JBoss 7.2 Final (from Git) ... client jar issues ?
                          raylite3 Apprentice

                          jaikiran pai wrote:

                           

                          I don't fully understand the setup. Do you have a jboss-ejb-client.properties in your classpath? If yes, what does it look like? If no, then the exception would be expected (unless you do programatic EJB client context configuration).

                           

                          If the properties are expected or the programmatic EJB client context configuration, why doesn't it throw a better message indicating as such? The generic "No EJB receiver available for handling" does not help me understand the cause of the exception. Is there a JIRA to improve the error handling and messages?

                          • 10. Re: JBoss 7.2 Final (from Git) ... client jar issues ?
                            jaikiran pai Master

                            Kiran Anantha wrote:

                             

                            jaikiran pai wrote:

                             

                            I don't fully understand the setup. Do you have a jboss-ejb-client.properties in your classpath? If yes, what does it look like? If no, then the exception would be expected (unless you do programatic EJB client context configuration).

                             

                            If the properties are expected or the programmatic EJB client context configuration, why doesn't it throw a better message indicating as such? The generic "No EJB receiver available for handling" does not help me understand the cause of the exception.

                            That log message indicates that the invocation failed because of a missing EJB receiver. I don't see what more clarity you need on that one. EJB receivers can be setup in numerous ways, how you do it is completely up to your application. If you use a jboss-ejb-client.properties then the EJB client API does that parsing and it does log the failure if anything fails. However, if you just skip the process of setting up the receivers, why would you expect the EJB client API to log an exception even before the invocation is done?

                            • 11. Re: JBoss 7.2 Final (from Git) ... client jar issues ?
                              jaikiran pai Master

                              Kiran Anantha wrote:

                               

                              jaikiran pai wrote:

                               

                              Kiran Anantha wrote:

                               

                              jaikiran pai wrote:

                               

                              I don't fully understand the setup. Do you have a jboss-ejb-client.properties in your classpath? If yes, what does it look like? If no, then the exception would be expected (unless you do programatic EJB client context configuration).

                               

                              If the properties are expected or the programmatic EJB client context configuration, why doesn't it throw a better message indicating as such? The generic "No EJB receiver available for handling" does not help me understand the cause of the exception.

                              That log message indicates that the invocation failed because of a missing EJB receiver. I don't see what more clarity you need on that one. EJB receivers can be setup in numerous ways, how you do it is completely up to your application. If you use a jboss-ejb-client.properties then the EJB client API does that parsing and it does log the failure if anything fails. However, if you just skip the process of setting up the receivers, why would you expect the EJB client API to log an exception even before the invocation is done?

                               

                              If the client requires the receivers to be setup and you skip it, that is an error that should be logged.

                               

                              So here's a question to you - when would you log that message or throw an error that a EJB context is missing a EJB receiver? And what would the message look like?

                              • 12. Re: JBoss 7.2 Final (from Git) ... client jar issues ?
                                millsp Newbie

                                OK if I understand correctly, I've modified my test cases to use 'remoting', where I set up the following properties :


                                            contextProps.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory" );

                                            contextProps.put("jboss.naming.client.ejb.context", true);

                                            contextProps.put(Context.SECURITY_PRINCIPAL, usr );
                                            contextProps.put(Context.SECURITY_CREDENTIALS, pwd );
                                            contextProps.put(Context.PROVIDER_URL, "remote://" + url );

                                 

                                ... and I'm looking up JNDI names in the following format :

                                 

                                    public static final String LOGIN_SLSB_REMOTE_JNDI = "cp-model/cp-model.jar/CPLoginSessionSEJB!com.cedar.cp.model.ejb.CPLoginSessionHome";
                                    public static final String LIST_SLSB_REMOTE_JNDI  = "cp-model/cp-model.jar/CPListSessionSEJB!com.cedar.cp.model.ejb.CPListSessionHome";

                                 

                                My first test case - where I repeatedly find an IC / home / remote / and invoke a method - works fine this way, however there's a problem when I try to use JNDI lookup results etc. in another thread.  I can look up a home i/f fine, but if I pass this to another thread and try to get a remote i/f from it, I get the following :

                                 

                                Using REMOTING only ...
                                04-Mar-2013 11:05:37 org.xnio.Xnio <clinit>
                                INFO: XNIO Version 3.0.7.GA
                                04-Mar-2013 11:05:37 org.xnio.nio.NioXnio <clinit>
                                INFO: XNIO NIO Implementation Version 3.0.7.GA
                                04-Mar-2013 11:05:37 org.jboss.remoting3.EndpointImpl <clinit>
                                INFO: JBoss Remoting version 3.2.14.GA
                                CPModelClient : main() :... found context
                                Case 1.  Got context, but get home & remote i/fs inside a new thread
                                CPModelClient : main() :... found LIST SEJB Home
                                CPModelClient : main() :... found LOGIN SEJB Home
                                Case 2.  Got home i/f, but get remote i/f inside a new thread
                                CPModelClient : main() :... found MODEL SEJB Home
                                java.lang.IllegalStateException: EJBCLIENT000025: No EJB receiver available for handling [appName:cp-model, moduleName:cp-model.jar, distinctName:] combination for invocation context org.jboss.ejb.client.EJBClientInvocationContext@13a78071
                                        at org.jboss.ejb.client.EJBClientContext.requireEJBReceiver(EJBClientContext.java:693)
                                        at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:116)
                                        at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183)
                                        at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:177)
                                        at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:161)
                                        at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:124)
                                        at $Proxy1.create(Unknown Source)
                                        at com.cedar.cp.model.client.CPModelClientThreadRemoting$2.run(CPModelClientThreadRemoting.java:140)
                                04-Mar-2013 11:05:37 org.jboss.ejb.client.remoting.VersionReceiver handleMessage
                                INFO: EJBCLIENT000017: Received server version 1 and marshalling strategies [river]
                                java.lang.IllegalStateException: EJBCLIENT000025: No EJB receiver available for handling [appName:cp-model, moduleName:cp-model.jar, distinctName:] combination for invocation context org.jboss.ejb.client.EJBClientInvocationContext@59e184cb
                                        at org.jboss.ejb.client.EJBClientContext.requireEJBReceiver(EJBClientContext.java:693)
                                        at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:116)
                                        at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183)
                                        at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:177)
                                        at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:161)
                                        at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:124)
                                        at $Proxy0.create(Unknown Source)
                                        at com.cedar.cp.model.client.CPModelClientThreadRemoting$1.run(CPModelClientThreadRemoting.java:108)

                                 

                                This is the code which breaks :

                                 

                                                final CPListSessionHome lihome = (CPListSessionHome) PortableRemoteObject.narrow(ic.lookup( LIST_SLSB_REMOTE_JNDI ), CPListSessionHome.class);
                                                System.out.println( "CPModelClient : main() :... found LIST SEJB Home");
                                                if( threadIt )
                                                {
                                                    Thread t2 = new Thread(){
                                                        public void run()
                                                        {
                                                            try
                                                            {
                                                                System.out.println( "Case 2.  Got home i/f, but get remote i/f inside a new thread");
                                                                CPListSessionRemote lirmt = lihome.create(); // THIS IS LINE 140
                                                                lirmt.listThings();
                                                            }
                                                            catch ( Exception e ) { e.printStackTrace(); }
                                                        }
                                                    };
                                                    t2.start();

                                 

                                We do a lot of threading in our application because it is a Swing GUI.

                                 

                                 

                                 

                                • 13. Re: JBoss 7.2 Final (from Git) ... client jar issues ?
                                  jaikiran pai Master

                                  millsp wrote:

                                   

                                   

                                  My first test case - where I repeatedly find an IC / home / remote / and invoke a method - works fine this way, however there's a problem when I try to use JNDI lookup results etc. in another thread.  I can look up a home i/f fine, but if I pass this to another thread and try to get a remote i/f from it, I get the following :

                                  There was a bug in remote-naming which was fixed (I think). Which version of remote-naming library is there in your client classpath?

                                  • 14. Re: JBoss 7.2 Final (from Git) ... client jar issues ?
                                    millsp Newbie

                                    I'm using the jboss-client.jar which our build from Git created.  Can I find out from within that which version of remote-naming it is using ?

                                    1 2 Previous Next