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

[millsp]

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)

[jaikiran]

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).

[millsp]

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

[jaikiran]

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.

[millsp]

            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

[jaikiran]

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.

[millsp]

> 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.

[jaikiran]

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

[millsp]

OK thanks - will review that and check our code.

[raylite3]

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?

[jaikiran]

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?

[jaikiran]

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?

[millsp]

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.

[jaikiran]

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?

[millsp]

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 ?