Skip to end of metadata
Go to start of metadata

This chapter explains how to invoke EJBs from a remote client by using the JNDI API to first lookup the bean proxy and then invoke on that proxy.

After you have read this article, do remember to take a look at Remote EJB invocations via JNDI - EJB client API or remote-naming project

Before getting into the details, we would like the users to know that we have introduced a new EJB client API, which is a JBoss specific API and allows invocation on remote EJBs. This client API isn't based on JNDI. So remote clients need not rely on JNDI API to invoke on EJBs. A separate document covering the EJB remote client API will be made available. For now, you can refer to the javadocs of the EJB client project at http://docs.jboss.org/ejbclient/. In this document, we'll just concentrate on the traditional JNDI based invocation on EJBs. So let's get started:

Deploying your EJBs on the server side:

Users who already have EJBs deployed on the server side can just skip to the next section.

As a first step, you'll have to deploy your application containing the EJBs on the AS7 server. If you want those EJBs to be remotely invocable, then you'll have to expose atleast one remote view for that bean. In this example, let's consider a simple Calculator stateless bean which exposes a RemoteCalculator remote business interface. We'll also have a simple stateful CounterBean which exposes a RemoteCounter remote business interface. Here's the code:

Let's package this in a jar (how you package it in a jar is out of scope of this chapter) named "jboss-as-ejb-remote-app.jar" and deploy it to the server. Make sure that your deployment has been processed successfully and there aren't any errors.

Writing a remote client application for accessing and invoking the EJBs deployed on the server

The next step is to write an application which will invoke the EJBs that you deployed on the server. In AS7, you can either choose to use the JBoss specific EJB client API to do the invocation or use JNDI to lookup a proxy for your bean and invoke on that returned proxy. In this chapter we will concentrate on the JNDI lookup and invocation and will leave the EJB client API for a separate chapter.

So let's take a look at what the client code looks like for looking up the JNDI proxy and invoking on it. Here's the entire client code which invokes on a stateless bean:

The entire server side and client side code is hosted at the github repo here https://github.com/jboss-jdf/jboss-as-quickstart/tree/master/ejb-remote

The code has some comments which will help you understand each of those lines. But we'll explain here in more detail what the code does. As a first step in the client code, we'll do a lookup of the EJB using a JNDI name. In AS7, for remote access to EJBs, you use the ejb: namespace with the following syntax:

For stateless beans:

For stateful beans:

The ejb: namespace identifies it as a EJB lookup and is a constant (i.e. doesn't change) for doing EJB lookups. The rest of the parts in the jndi name are as follows:

app-name : This is the name of the .ear (without the .ear suffix) that you have deployed on the server and contains your EJBs.

  • Java EE 6 allows you to override the application name, to a name of your choice by setting it in the application.xml. If the deployment uses uses such an override then the app-name used in the JNDI name should match that name.
  • EJBs can also be deployed in a .war or a plain .jar (like we did in step 1). In such cases where the deployment isn't an .ear file, then the app-name must be an empty string, while doing the lookup.

module-name : This is the name of the .jar (without the .jar suffix) that you have deployed on the server and the contains your EJBs. If the EJBs are deployed in a .war then the module name is the .war name (without the .war suffix).

  • Java EE 6 allows you to override the module name, by setting it in the ejb-jar.xml/web.xml of your deployment. If the deployment uses such an override then the module-name used in the JNDI name should match that name.
  • Module name part cannot be an empty string in the JNDI name

distinct-name : This is a JBoss AS7 specific name which can be optionally assigned to the deployments that are deployed on the server. More about the purpose and usage of this will be explained in a separate chapter. If a deployment doesn't use distinct-name then, use an empty string in the JNDI name, for distinct-name

bean-name : This is the name of the bean for which you are doing the lookup. The bean name is typically the unqualified classname of the bean implementation class, but can be overriden through either ejb-jar.xml or via annotations. The bean name part cannot be an empty string in the JNDI name.

fully-qualified-classname-of-the-remote-interface : This is the fully qualified class name of the interface for which you are doing the lookup. The interface should be one of the remote interfaces exposed by the bean on the server. The fully qualified class name part cannot be an empty string in the JNDI name.

For stateful beans, the JNDI name expects an additional "?stateful" to be appended after the fully qualified interface name part. This is because for stateful beans, a new session gets created on JNDI lookup and the EJB client API implementation doesn't contact the server during the JNDI lookup to know what kind of a bean the JNDI name represents (we'll come to this in a while). So the JNDI name itself is expected to indicate that the client is looking up a stateful bean, so that an appropriate session can be created.

Now that we know the syntax, let's see our code and check what JNDI name it uses. Since our stateless EJB named CalculatorBean is deployed in a jboss-as-ejb-remote-app.jar (without any ear) and since we are looking up the org.jboss.as.quickstarts.ejb.remote.stateless.RemoteCalculator remote interface, our JNDI name will be:

That's what the lookupRemoteStatelessCalculator() method in the above client code uses.

For the stateful EJB named CounterBean which is deployed in hte same jboss-as-ejb-remote-app.jar and which exposes the org.jboss.as.quickstarts.ejb.remote.stateful.RemoteCounter, the JNDI name will be:

That's what the lookupRemoteStatefulCounter() method in the above client code uses.

Now that we know of the JNDI name, let's take a look at the following piece of code in the lookupRemoteStatelessCalculator():

Here we are creating a JNDI InitialContext object by passing it some JNDI properties. The Context.URL_PKG_PREFIXES is set to org.jboss.ejb.client.naming. This is necessary because we should let the JNDI API know what handles the ejb: namespace that we use in our JNDI names for lookup. The "org.jboss.ejb.client.naming" has a URLContextFactory implementation which will be used by the JNDI APIs to parse and return an object for ejb: namespace lookups. You can either pass these properties to the constructor of the InitialContext class or have a jndi.properites file in the classpath of the client application, which (atleast) contains the following property:

So at this point, we have setup the InitialContext and also have the JNDI name ready to do the lookup. You can now do the lookup and the appropriate proxy which will be castable to the remote interface that you used as the fully qualified class name in the JNDI name, will be returned. Some of you might be wondering, how the JNDI implementation knew which server address to look, for your deployed EJBs. The answer is in AS7, the proxies returned via JNDI name lookup for ejb: namespace do not connect to the server unless an invocation on those proxies is done.

Now let's get to the point where we invoke on this returned proxy:

We can see here that the proxy returned after the lookup is used to invoke the add(...) method of the bean. It's at this point that the JNDI implementation (which is backed by the JBoss EJB client API) needs to know the server details. So let's now get to the important part of setting up the EJB client context properties.

Setting up EJB client context properties

A EJB client context is a context which contains contextual information for carrying out remote invocations on EJBs. This is a JBoss specific API. The EJB client context can be associated with multiple EJB receivers. Each EJB receiver is capable of handling invocations on different EJBs. For example, an EJB receiver "Foo" might be able to handle invocation on a bean identified by app-A/module-A/distinctinctName-A/Bar!RemoteBar, whereas a EJB receiver named "Blah" might be able to handle invocation on a bean identified by app-B/module-B/distinctName-B/BeanB!RemoteBean. Each such EJB receiver knows about what set of EJBs it can handle and each of the EJB receiver knows which server target to use for handling the invocations on the bean. For example, if you have a AS7 server at 10.20.30.40 IP address which has its remoting port opened at 4447 and if that's the server on which you deployed that CalculatorBean, then you can setup a EJB receiver which knows its target address is 10.20.30.40:4447. Such an EJB receiver will be capable enough to communicate to the server via the JBoss specific EJB remote client protocol (details of which will be explained in-depth in a separate chapter).

Now that we know what a EJB client context is and what a EJB receiver is, let's see how we can setup a client context with 1 EJB receiver which can connect to 10.20.30.40 IP address at port 4447. That EJB client context will then be used (internally) by the JNDI implementation to handle invocations on the bean proxy.

The client will have to place a jboss-ejb-client.properties file in the classpath of the application. The jboss-ejb-client.properties can contain the following properties:

The above properties file is just an example. The actual file that was used for this sample program is available here for reference https://github.com/jboss-jdf/jboss-as-quickstart/blob/master/ejb-remote/client/src/main/resources/jboss-ejb-client.properties

We'll see what each of it means.

First the endpoint.name property. We mentioned earlier that the EJB receivers will communicate with the server for EJB invocations. Internally, they use JBoss Remoting project to carry out the communication. The endpoint.name property represents the name that will be used to create the client side of the enpdoint. The endpoint.name property is optional and if not specified in the jboss-ejb-client.properties file, it will default to "config-based-ejb-client-endpoint" name.

Next is the remote.connectionprovider.create.options.<....> properties:

The "remote.connectionprovider.create.options." property prefix can be used to pass the options that will be used while create the connection provider which will handle the "remote:" protocol. In this example we use the "remote.connectionprovider.create.options." property prefix to pass the "org.xnio.Options.SSL_ENABLED" property value as false. That property will then be used during the connection provider creation. Similarly other properties can be passed too, just append it to the "remote.connectionprovider.create.options." prefix

Next we'll see:

This is where you define the connections that you want to setup for communication with the remote server. The "remote.connections" property uses a comma separated value of connection "names". The connection names are just logical and are used grouping together the connection configuration properties later on in the properties file. The example above sets up a single remote connection named "default". There can be more than one connections that are configured. For example:

Here we are listing 2 connections named "one" and "two". Ultimately, each of the connections will map to a EJB receiver. So if you have 2 connections, that will setup 2 EJB receivers that will be added to the EJB client context. Each of these connections will be configured with the connection specific properties as follows:

As you can see we are using the "remote.connection.<connection-name>." prefix for specifying the connection specific property. The connection name here is "default" and we are setting the "host" property of that connection to point to 10.20.30.40. Similarly we set the "port" for that connection to 4447.

By default AS7 uses 4447 as the remoting port. The EJB client API uses the remoting port for communicating with the server for remote invocations, so that's the port we use in our client programs (unless the server is configured for some other remoting port)

The given user/password must be set by using the command bin/add-user.sh (or.bat).
The user and password must be set because the security-realm is enabled for the subsystem remoting (see standalone*.xml or domain.xml) by default.
If you do not need the security for remoting you might remove the attribute security-realm in the configuration.

security-realm is possible since 7.1.0.FINAL and enabled by default.

We then use the "remote.connection.<connection-name>.connect.options." property prefix to setup options that will be used during the connection creation.

Here's an example of setting up multiple connections with different properties for each of those:

As you can see we setup 2 connections "one" and "two" which both point to "localhost" as the "host" but different ports. Each of these connections will internally be used to create the EJB receivers in the EJB client context.

So that's how the jboss-ejb-client.properties file can be setup and placed in the classpath.

Using a different file for setting up EJB client context

The EJB client code will by default look for jboss-ejb-client.properties in the classpath. However, you can specify a different file of your choice by setting the "jboss.ejb.client.properties.file.path" system property which points to a properties file on your filesystem, containing the client context configurations. An example for that would be "-Djboss.ejb.client.properties.file.path=/home/me/my-client/custom-jboss-ejb-client.properties"

Setting up the client classpath with the jars that are required to run the client application

Starting JBoss AS 7.1.0.Final, a jboss-client jar is shipped in the distribution. It's available at JBOSS_HOME/bin/client/jboss-client-7.1.0.Final.jar. Place this jar in the classpath of your client application.

If you are using Maven to build the client application, then please follow the instructions in the JBOSS_HOME/bin/client/README.txt to add this jar as a Maven dependency.

Summary

In the above examples, we saw what it takes to invoke a EJB from a remote client. To summarize:

  • On the server side you need to deploy EJBs which expose the remote views.
  • On the client side you need a client program which:
    • Has a jboss-ejb-client.properties in its classpath to setup the server connection information
    • Either has a jndi.properties to specify the java.naming.factory.url.pkgs property or passes that as a property to the InitialContext constructor
    • Setup the client classpath to include the jboss-client jar that's required for remote invocation of the EJBs. The location of the jar is mentioned above. You'll also need to have your application's bean interface jars and other jars that are required by your application, in the client classpath
Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Nov 27, 2011

    What are the ports used for EJB lookup? By this I mean what ports need to be changed on the server as well as the client (Context.PROVIDER_URL) side for using different ports...

  2. Dec 12, 2011

    Maven dependencies for current AS7.1.CR1 JBoss repository >https://repository.jboss.org/nexus/content/groups/public-jboss

    group-id         artifactId                 version
    org.jboss.sasl     jboss-sasl             1.0.0.Beta9
                ( and during runtime ....)

    org.jboss                       jboss-ejb-client                1.0.0.Beta7
    org.jboss.marshalling     jboss-marshalling-river      1.3.4.GA
    org.jboss.xnio                xnio-nio                          3.0.0.CR5
    org.jboss.remoting3        jboss-remoting                3.2.0.CR6
    org.jboss.marshalling      jboss-marshalling            1.3.4.GA
    org.jboss.xnio                xnio-api                          3.0.0.CR5
    org.jboss.logging            jboss-logging                  3.1.0.CR2
    org.jboss.spec.javax.ejb  jboss-ejb-api_3.1_spec   1.0.1.Final

  3. Jan 03, 2012

    I think there is one jar file more needed ... :

    jboss-jacc-api_1.4_spec-1.0.1.Final.jar

    Without it I'm getting this Exception:

    Exception in thread "main" java.lang.NoClassDefFoundError: javax/security/jacc/PolicyContextException
         [java]     at java.lang.Class.getDeclaredMethods0(Native Method)
         [java]     at java.lang.Class.privateGetDeclaredMethods(Class.java:2427)
         [java]     at java.lang.Class.privateGetPublicMethods(Class.java:2547)
         [java]     at java.lang.Class.getMethods(Class.java:1410)
         [java]     at sun.misc.ProxyGenerator.generateClassFile(ProxyGenerator.java:409)
         [java]     at sun.misc.ProxyGenerator.generateProxyClass(ProxyGenerator.java:306)
         [java]     at java.lang.reflect.Proxy.getProxyClass(Proxy.java:501)
         [java]     at org.jboss.ejb.client.EJBLocator.<init>(EJBLocator.java:77)
         [java]     at org.jboss.ejb.client.StatelessEJBLocator.<init>(StatelessEJBLocator.java:44)
         [java]     at org.jboss.ejb.client.naming.ejb.EjbNamingContext.doCreateProxy(EjbNamingContext.java:137)
         [java]     at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createEjbProxy(EjbNamingContext.java:113)
         [java]     at org.jboss.ejb.client.naming.ejb.EjbNamingContext.lookup(EjbNamingContext.java:96)
         [java]     at javax.naming.InitialContext.lookup(InitialContext.java:392)
         [java]     at TestKrb5.GetAction.run(TestServiceClient.java:131)

  4. Feb 06, 2012

    *Slightly* amended Maven deps for current 7.1.0.CR1b (repository as per Wolf-Dieter above: >https://repository.jboss.org/nexus/content/groups/public-jboss): 

    <dependency>
            <groupId>org.jboss.spec.javax.transaction</groupId>
            <artifactId>jboss-transaction-api_1.1_spec</artifactId>
            <version>1.0.0.Final</version>
        </dependency>
        <dependency>
            <groupId>org.jboss.spec.javax.ejb</groupId>
            <artifactId>jboss-ejb-api_3.1_spec</artifactId>
            <version>1.0.1.Final</version>
        </dependency>
        <dependency>
            <groupId>org.jboss</groupId>
            <artifactId>jboss-ejb-client</artifactId>
            <version>1.0.0.Beta11</version>
        </dependency>
        <dependency>
            <groupId>org.jboss.marshalling</groupId>
            <artifactId>jboss-marshalling</artifactId>
            <version>1.3.4.GA</version>
        </dependency>
        <dependency>
            <groupId>org.jboss.xnio</groupId>
            <artifactId>xnio-api</artifactId>
            <version>3.0.0.CR7</version>
        </dependency>
        <dependency>
            <groupId>org.jboss.remoting3</groupId>
            <artifactId>jboss-remoting</artifactId>
            <version>3.2.0.CR8</version>
        </dependency>
        <dependency>
            <groupId>org.jboss.logging</groupId>
            <artifactId>jboss-logging</artifactId>
            <version>3.1.0.CR2</version>
        </dependency>
        <dependency>
            <groupId>org.jboss.xnio</groupId>
            <artifactId>xnio-nio</artifactId>
            <version>3.0.0.CR7</version>
        </dependency>
        <dependency>
            <groupId>org.jboss.sasl</groupId>
            <artifactId>jboss-sasl</artifactId>
            <version>1.0.0.Beta9</version>
        </dependency>
        <dependency>
            <groupId>org.jboss.marshalling</groupId>
            <artifactId>jboss-marshalling-river</artifactId>
            <version>1.3.4.GA</version>
        </dependency>
                <artifactId>jboss-transaction-api_1.1_spec</artifactId>
                <version>1.0.0.Final</version>
            </dependency>
            <dependency>
                <groupId>org.jboss.spec.javax.ejb</groupId>
                <artifactId>jboss-ejb-api_3.1_spec</artifactId>
                <version>1.0.1.Final</version>
            </dependency>
            <dependency>
                <groupId>org.jboss</groupId>
                <artifactId>jboss-ejb-client</artifactId>
                <version>1.0.0.Beta11</version>
            </dependency>
             <dependency>
                <groupId>org.jboss.marshalling</groupId>
                <artifactId>jboss-marshalling</artifactId>
                <version>1.3.4.GA</version>
            </dependency>
             <dependency>
                <groupId>org.jboss.xnio</groupId>
                <artifactId>xnio-api</artifactId>
                <version>3.0.0.CR7</version>
            </dependency>
            <dependency>
                <groupId>org.jboss.remoting3</groupId>
                <artifactId>jboss-remoting</artifactId>
                <version>3.2.0.CR8</version>
            </dependency>
               <dependency>
                <groupId>org.jboss.logging</groupId>
                <artifactId>jboss-logging</artifactId>
                <version>3.1.0.CR2</version>
            </dependency>
            <dependency>
                <groupId>org.jboss.xnio</groupId>
                <artifactId>xnio-nio</artifactId>
                <version>3.0.0.CR7</version>
            </dependency>
            <dependency>
                <groupId>org.jboss.sasl</groupId>
                <artifactId>jboss-sasl</artifactId>
                <version>1.0.0.Beta9</version>
            </dependency> 
            <dependency>
                <groupId>org.jboss.marshalling</groupId>
                <artifactId>jboss-marshalling-river</artifactId>
                <version>1.3.4.GA</version>
            </dependency>
    
  5. Apr 08, 2012

    Very thorough article, thank you. Two questions:

    1. How to send the username and password from the client when the Bean is secured using Java EE security (@DeclareRoles, @RolesAllowed)?

    2. What if the Bean does not have a remote view? How'd the look up syntax change then?

  6. Apr 11, 2012

    I found that if packaging the EJBs in a WAR, the moduleName to use in the remote client example is the one from web.xml

  7. Apr 27, 2012

    Hi there all, I am having a small problem with finding bean with JNDI (using this example from page). Jboss 7.1.1 and always giving an error:

    exception in thread "main" javax.naming.NoInitialContextException: Need to specify class name in environment or system property, or as an applet parameter, or in an application resource file:  java.naming.factory.initial

    Even after I make this extra entry to properties : jndiProperties.put("java.naming.factory.initial","org.jnp.interfaces.NamingContextFactory");

    I get another error:

    Exception in thread "main" javax.naming.NoInitialContextException: Cannot instantiate class: org.jnp.interfaces.NamingContextFactory [Root exception is java.lang.ClassNotFoundException: org.jnp.interfaces.NamingContextFactory]

    what am I missing here? I think I have done everything like in this tutorial (beans created and properly deployed to jboss).

    1. May 29, 2013

      Hi Ernest

      Did you find any solution for the problem you mentioned? I'm having the same issue

      exception in thread "main" javax.naming.NoInitialContextException: Need to specify class name in environment or system property, or as an applet parameter, or in an application resource file:  java.naming.factory.initial

      Even after I make this extra entry to properties : jndiProperties.put("java.naming.factory.initial","org.jnp.interfaces.NamingContextFactory");

      I get another error:

      Exception in thread "main" javax.naming.NoInitialContextException: Cannot instantiate class: org.jnp.interfaces.NamingContextFactory [Root exception is java.lang.ClassNotFoundException: org.jnp.interfaces.NamingContextFactory]

      Jaikiran Pai,

      If you know the solution please feel free to reply back.

      Thanks!!!

  8. May 11, 2012

    We have big problems porting JBoss 5 applications to JBoss 7 because of the new propriatary JNDI name space "ejb:" - not because of the prefix "ejb:" instead of global JNDI names ("java:global"), but because of the suffix "?stateful" for stateful beans.

    You say, that the client has to supply the information "stateful" or "stateless" because of the way how JBoss Remoting is creating the connection to the serverside object and that the client code "knows" the ejb session type, but that is not true in general. Our clients use some sort of locator pattern with bean name, application name, fully quallified interface name etc. for locating the serverside objects. This locator has no clue at all, if the targeted object is stateful or not.

    We have been using this locator for years now, meaning that extending it by some additional (and JBoss specific!) parameter carrying the session type would be very expensive - leading to the fact, that porting to JBoss 7 is no option, but stay with JBoss 5 instead - or head for GlassFish. I don't think that is the way you would recommend people to go, right?

    Or did I miss something and there is the good old way of looking up an ejb via java:global or something similar?

    Regards

    Dirk

    1. Jun 10, 2012

      Dirk, you might be interested in this article https://docs.jboss.org/author/display/AS71/Remote+EJB+invocations+via+JNDI+-+EJB+client+API+or+remote-naming+project. Read through it completely to decide if the other approach explained in that article is feasible for your application.

  9. May 26, 2012

    And we have big problems porting from AS 5 to 7, because the JAAS/ClientLoginModule way of getting the security information from the client to the server doesn't work any more.

    Will this feature come back or di you only provide the new SASL way?

    Best regards,
    Jochen

    1. Jun 10, 2012

      Jochen, please create a discussion here https://community.jboss.org/community/jbossas7?view=discussions with the relevant details. Someone with more knowledge about the security related configurations/implementation in AS7 might be able to help.

  10. Jun 10, 2012

    From document  it is clear that we can use either jndi.properties file or can pass properties through the constructor of InitialContext. But can we we programmatically configure and replace jboss-ejb-client.properties ?

    Best regards,

    Suraj

    1. Jun 10, 2012

      Suraj, to answer your question, we'll need a few more details about your use case. Please create a discussion in the AS7 user forum here https://community.jboss.org/community/jbossas7?view=discussions and add the relevant details on what you are trying to achieve.

  11. Jun 11, 2012

    This is comment or question about the new JNDI format of the statless session bean string.  The section above shows the following value:ejb:/jboss-as-ejb-remote-app//CalculatorBean!org.jboss.as.quickstarts.ejb.remote.stateless.RemoteCalculator

    notice the // where I believe the distinct name would be.   This is different from the version in that class that I downloaded with the latest quick starts which is 7.1.1.CR2.  It only has one slash instead of two.   I was able to get the quick start code running using Maven.   Which format is correct?  If you use null for the distinct name, does that mean you drop one of the slashes?

    1. Jun 12, 2012

      This is different from the version in that class that I downloaded with the latest quick starts which is 7.1.1.CR2

      I would recommend that you use the 7.1.1.Final one. Or can you point me to that quickstart which uses a syntax other than ejb:app-name/module-name/distinct-name/bean-name!interface syntax?

      The default distinct name is an empty string and that's why you will see jndi names like ejb:foo/bar//beanname!interface (i.e. 2 doubles slashes after the module-name, since the distinct name is an empty string).

      1. Jun 18, 2012

        My comment was comparing the quickstart code (even at the top of the page) that I downloaded vs the online documentation. 

        In the section below where you discuss the components of the naming format, there are two small samples, one for the

        stateless and one for stateful.  Those snippets include "//".  

  12. Jul 27, 2012

    THIS EXAMPLE DON'T WORK IN JBOSS-AS-7.0.2.FINAL

    STACKTRACE:

    27-lug-2012 22.05.08 org.xnio.Xnio <clinit>
    INFO: XNIO Version 3.0.3.GA
    27-lug-2012 22.05.08 org.xnio.nio.NioXnio <clinit>
    INFO: XNIO NIO Implementation Version 3.0.3.GA
    27-lug-2012 22.05.08 org.jboss.remoting3.EndpointImpl <clinit>
    INFO: JBoss Remoting version 3.2.2.GA
    27-lug-2012 22.05.13 org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector setupEJBReceivers
    WARN: Could not register a EJB receiver for connection to remote://127.0.0.1:4447
    java.lang.RuntimeException: Operation failed with status WAITING at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:93) at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.setupEJBReceivers(ConfigBasedEJBClientContextSelector.java:115) at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.<init>(ConfigBasedEJBClientContextSelector.java:77) at org.jboss.ejb.client.EJBClientContext.<clinit>(EJBClientContext.java:76) at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:120) at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:104) at $Proxy0.add(Unknown Source) at it.fernando.ejb.remote.client.RemoteEJBClient.invokeStatelessBean(RemoteEJBClient.java:50) at it.fernando.ejb.remote.client.RemoteEJBClient.main(RemoteEJBClient.java:31)
    Exception in thread "main" java.lang.IllegalStateException: No EJB receiver available for handling [appName:,modulename:jboss-as-ejb-remote-app,distinctname:] combination at org.jboss.ejb.client.EJBClientContext.requireEJBReceiver(EJBClientContext.java:530) at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:84) at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:175) at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:136) at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:121) at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:104) at $Proxy0.add(Unknown Source) at it.fernando.ejb.remote.client.RemoteEJBClient.invokeStatelessBean(RemoteEJBClient.java:50) at it.fernando.ejb.remote.client.RemoteEJBClient.main(RemoteEJBClient.java:31)
    27-lug-2012 22.05.08 org.xnio.Xnio <clinit>

    INFO: XNIO Version 3.0.3.GA

    27-lug-2012 22.05.08 org.xnio.nio.NioXnio <clinit>

    INFO: XNIO NIO Implementation Version 3.0.3.GA

    27-lug-2012 22.05.08 org.jboss.remoting3.EndpointImpl <clinit>

    INFO: JBoss Remoting version 3.2.2.GA

    27-lug-2012 22.05.13 org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector setupEJBReceivers

    WARN: Could not register a EJB receiver for connection to remote://127.0.0.1:4447

    java.lang.RuntimeException: Operation failed with status WAITING

    at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:93)

    at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.setupEJBReceivers(ConfigBasedEJBClientContextSelector.java:115)

    at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.<init>(ConfigBasedEJBClientContextSelector.java:77)

    at org.jboss.ejb.client.EJBClientContext.<clinit>(EJBClientContext.java:76)

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

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

    at $Proxy0.add(Unknown Source)

    at it.fernando.ejb.remote.client.RemoteEJBClient.invokeStatelessBean(RemoteEJBClient.java:50)

    at it.fernando.ejb.remote.client.RemoteEJBClient.main(RemoteEJBClient.java:31)

    Exception in thread "main" java.lang.IllegalStateException: No EJB receiver available for handling [appName:,modulename:jboss-as-ejb-remote-app,distinctname:] combination

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

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

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

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

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

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

    at $Proxy0.add(Unknown Source)

    at it.fernando.ejb.remote.client.RemoteEJBClient.invokeStatelessBean(RemoteEJBClient.java:50)

    at it.fernando.ejb.remote.client.RemoteEJBClient.main(RemoteEJBClient.java:31)

    (PS. The example is the same, I changed the package only)

    1. Jul 27, 2012

      Hi Fernando,

      as this is a documentation for 7.1 an example might not work for former releases, you should use AS7.1.

      Also I would recommend to use the forum AS7 for questions.

      1. Jul 30, 2012

        Not working on 7.1.1.Final "Brontes" either. To get it working, I've set this properties (besides java.naming.factory.url.pkgs=org.jboss.ejb.client.naming) in the jndi.properties file

        -----

        java.naming.factory.initial=org.jboss.naming.remote.client.InitialContextFactory
        java.naming.provider.url=remote://localhost:4447
        jboss.naming.client.ejb.context=true

        -----

        Without any of them, it just doesn't work (No EJB receiver available for handling).

        I use jndi name like:
        ejb:<app-name>/<module-name>//<bean-name>!<fully-qualified-classname-of-the-remote-interface>

        1. Jul 30, 2012

          Pablo,

          I struggled for a while with the remote ejb lookups and created a posting here where I was finally able to get

          things working.

          https://community.jboss.org/message/748461#748461

          The other question I had previously on this page - which I don't think I ever got a good response on -

          was the usage of the "//" in the middle of the JNDI name which was for the 'distinct name' but I have been

          successful omitting the distinct name and not including the extra "/" in the name.

          Hope this helps, if not - sorry for the intrusion!  :-)

          1. Jul 30, 2012

            Hi Mike,

            Yes, after all the tests I've run, I've seen that the extra "/" is not
            needed, but for being purist... :P

            Anyway, as I could see in your post, you've also has to set the
            initial context factory and the provider URL to get it working don't
            you?

            Is there a chance that the quickstart example is missing that part?

            Thanks for the reply and sorry for my English!

            1. Jul 30, 2012

              Hi Pablo,

              it should work in AS7.1.1. But please open a community thread here https://community.jboss.org/en/jbossas7 for this.

              The documentation should not be a good place for this longer discussion.

            2. Jul 30, 2012

              Yes, for a remote ejb lookup I had to set the properties for the InitialContent. 

              The reason for my initial posting on this page was the "//" - the quickstart that I have, that works,

              does NOT include the extra "/".  My concern was that someone reading this page would include

              the "//" and run into problems, yet the example code (ejb-remote/client) does NOT have "//".

        2. Aug 27, 2012

          Thanks, Pablo. Your tip saved my problem :-D

          1. Aug 27, 2012

            Hey! you are welcome... anyway, you can check this thread to see the correct solution! ;-)

  13. Aug 03, 2012

    Thanks all. Now this work properly, from local and remote interfaces... I'm using JBoss AS 7.1.1.Final

    Best regards

    Fernando

  14. Sep 14, 2012

    This guide does not appear to tell you how to write an EJB client where the EJB your connecting to is on a cluster. In the past you just used HA-JNDI and give at least one live server in the naming url but the new EJB client stuff does not appear to discover cluster members in the same way

  15. Oct 10, 2012

    Hello There! Could anybody give me a clue about this exception:

    java.lang.IllegalStateException: No EJB receiver available for handling [appName:myDaily-ear,modulename:myDaily-ejb-jar,distinctname:] combination

    I got a lot of the erros reported by a lot of people here and could make it work, but now I can't issue this problem. If it can help you, There's this log in the log of jboss:

    17:37:59,974 INFO  [org.jboss.as.naming] (Remoting "romerito" task-3) JBAS011806: Channel end notification received, closing channel Channel ID 395b14c2 (inbound) of Remoting connection 068fda59 to null

    I'm using the Standalone one!

    Thanks in advanced,

    Rômero Ricardo

  16. Oct 10, 2012

    Rômero, jboss show that after deploy my ejb:

    00:37:00,217 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-2) JNDI bindings for session bean named PlaceBid in deployment unit deployment "ActionBazaar.jar" are as follows: java:global/ActionBazaar/PlaceBid!com.ejb3inaction.actionbazaar.buslogic.PlaceBid java:app/ActionBazaar/PlaceBid!com.ejb3inaction.actionbazaar.buslogic.PlaceBid java:module/PlaceBid!com.ejb3inaction.actionbazaar.buslogic.PlaceBid java:jboss/exported/ActionBazaar/PlaceBid!com.ejb3inaction.actionbazaar.buslogic.PlaceBid java:global/ActionBazaar/PlaceBid java:app/ActionBazaar/PlaceBid java:module/PlaceBid
    00:37:00,217 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-2) JNDI bindings for session bean named PlaceBid in deployment unit deployment "ActionBazaar.jar" are as follows:

    java:global/ActionBazaar/PlaceBid!com.ejb3inaction.actionbazaar.buslogic.PlaceBid

    java:app/ActionBazaar/PlaceBid!com.ejb3inaction.actionbazaar.buslogic.PlaceBid

    java:module/PlaceBid!com.ejb3inaction.actionbazaar.buslogic.PlaceBid

    java:jboss/exported/ActionBazaar/PlaceBid!com.ejb3inaction.actionbazaar.buslogic.PlaceBid

    java:global/ActionBazaar/PlaceBid

    java:app/ActionBazaar/PlaceBid

    java:module/PlaceBid

    In my client application I do that:

    context.lookup("/ActionBazaar/PlaceBid!com.ejb3inaction.actionbazaar.buslogic.PlaceBid")

  17. Feb 13, 2013

    I am getting this error on Stand-alone client side.

    3-Feb-2013 15:19:55 org.jboss.ejb.client.EJBClient <clinit>

    INFO: JBoss EJB Client version 1.0.5.Final

    Exception in thread "main" java.lang.ClassFormatError: Absent Code attribute in method that is not native or abstract in class file javax/transaction/SystemException

    at java.lang.ClassLoader.defineClass1(Native Method)

    at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)

    at java.lang.ClassLoader.defineClass(ClassLoader.java:615)

    at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)

    at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)

    at java.net.URLClassLoader.access$000(URLClassLoader.java:58)

    at java.net.URLClassLoader$1.run(URLClassLoader.java:197)

    at java.security.AccessController.doPrivileged(Native Method)

    at java.net.URLClassLoader.findClass(URLClassLoader.java:190)

    at java.lang.ClassLoader.loadClass(ClassLoader.java:306)

    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)

    at java.lang.ClassLoader.loadClass(ClassLoader.java:247)

    at org.jboss.ejb.client.remoting.ProtocolV1ClassTable.<clinit>(ProtocolV1ClassTable.java:83)

    at org.jboss.ejb.client.remoting.AbstractMessageWriter.getMarshaller(AbstractMessageWriter.java:97)

    at org.jboss.ejb.client.remoting.AbstractMessageWriter.prepareForMarshalling(AbstractMessageWriter.java:73)

    at org.jboss.ejb.client.remoting.MethodInvocationMessageWriter.writeMessage(MethodInvocationMessageWriter.java:90)

    at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.processInvocation(RemotingConnectionEJBReceiver.java:199)

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

    at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:43)

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

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

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

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

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

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

    at $Proxy0.add(Unknown Source)

    at com.test.TetEjbClass.main(TetEjbClass.java:37)

    On server side I see

    15:19:55,441 ERROR [org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver] (Remoting "new-lt7-0064" task-2) Exception on channel Channel ID 1cf0425a (inbound) of Remoting connection 71781ce4 to /127.0.0.1:64506 from message org.jboss.remoting3.remote.InboundMessage$3@84e5921: java.io.EOFException: Read past end of file
    at org.jboss.marshalling.SimpleDataInput.eofOnRead(SimpleDataInput.java:126) [jboss-marshalling-1.3.11.GA.jar:1.3.11.GA]
    at org.jboss.marshalling.SimpleDataInput.readUnsignedByteDirect(SimpleDataInput.java:263) [jboss-marshalling-1.3.11.GA.jar:1.3.11.GA]
    at org.jboss.marshalling.SimpleDataInput.readUnsignedByte(SimpleDataInput.java:224) [jboss-marshalling-1.3.11.GA.jar:1.3.11.GA]
    at org.jboss.marshalling.river.RiverUnmarshaller.start(RiverUnmarshaller.java:1186)
    at org.jboss.as.ejb3.remote.protocol.versionone.AbstractMessageHandler.prepareForUnMarshalling(AbstractMessageHandler.java:240)
    at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:104)
    at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:170)
    at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:437) [jboss-remoting-3.2.3.GA.jar:3.2.3.GA]
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_37]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_37]
    at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_37]

    15:19:55,456 INFO  [org.jboss.as.naming] (Remoting "new-lt7-0064" task-4) JBAS011806: Channel end notification received, closing channel Channel ID 6b2d51e8 (inbound) of Remoting connection 71781ce4 to null

    Any help is highly appreciated.

    Deployed on AS 7.1.1final and using jboss-client.jar from bin/client to make the EJB call standalone.
    All settings same as in tutorial above

    1. Feb 13, 2013

      ok solved my issue by looking into the pom in the client side in the example above.

      had to include

       <dependency>
                  <groupId>org.jboss.spec</groupId>
                  <artifactId>jboss-javaee-6.0</artifactId>
                  <version>3.0.2.Final</version>
                  <type>pom</type>
                  <scope>import</scope>
               </dependency>
       <dependency>

                 

      Or is this because we are using a stand-alone client hence need to include the above?

      Ideally one would want to us ethe Java ee6 api

      <dependency>

      <groupId>javax</groupId>

      <artifactId>javaee-api</artifactId>

      <version>6.0</version>

      <scope>provided</scope>

      </dependency>

  18. Feb 14, 2013

    Is there a documentation of everything that can be configured via jboss-ejb-client.properties?

    I found examples on the internet using "invocation.timeout", "reconnect.tasks.timeout", "deployment.node.selector", etc., but don't know how to use them exactly....

    E.g. is "invocation.timeout" the same as the remoting timeout that you could configure in JBoss 5.x on the server side?....

    1. Feb 15, 2013

      Some configuration properties can be found in the EJBCLIENT documentation, but it is only partial published there is still a lot of work to do.

  19. Mar 05, 2013

    I am migrating some ejbs to 7.1 and see WARNING message about not registering EJB receivers. Here are the config file details

    ejb-client.properties

    remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false

    remote.connections=default

    reconnect.tasks.timeout=15000

    remote.connection.default.host=localhost

    remote.connection.default.port=4447

    #remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false

    remote.connection.default.connect.timeout=35000

    remote.connection.default.username=user1

    remote.connection.default.password=pass

    JNDI.properties

    java.naming.factory.initial=org.jboss.naming.remote.client.InitialContextFactory
    java.naming.factory.url.pkgs=org.jboss.ejb.client.naming
    java.naming.provider.url=remote://localhost:4447
    java.naming.security.principal=user1
    java.naming.security.credentials=pass
    jboss.naming.client.ejb.context=true

    The WARNING
    17:59:34,294 WARN  [org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector] (ServerService Thread Pool -- 43) Could not register a EJB receiver for connection to remote://localhost:4447: java.lang.RuntimeException: Operation failed with status WAITING
    at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:93) [jboss-ejb-client-1.0.5.Final.jar:1.0.5.Final]
    at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.setupEJBReceivers(ConfigBasedEJBClientContextSelector.java:121) [jboss-ejb-client-1.0.5.Final.jar:1.0.5.Final]
    at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.<init>(ConfigBasedEJBClientContextSelector.java:78) [jboss-ejb-client-1.0.5.Final.jar:1.0.5.Final]
    at org.jboss.ejb.client.EJBClientContext.<clinit>(EJBClientContext.java:77) [jboss-ejb-client-1.0.5.Final.jar:1.0.5.Final]
    at org.jboss.as.ejb3.remote.DefaultEjbClientContextService$SetSelectorAction.run(DefaultEjbClientContextService.java:138) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
    at org.jboss.as.ejb3.remote.DefaultEjbClientContextService$SetSelectorAction.run(DefaultEjbClientContextService.java:128) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final]
    at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.6.0]

    Exception on EJB method invocation

    18:07:50,683 INFO  [stdout] (http--127.0.0.1-8081-1)    at java.lang.Thread.run(Thread.java:619)
    18:07:50,683 INFO  [stdout] (http--127.0.0.1-8081-1) Caused by: java.lang.IllegalStateException: No
    EJB receiver available for handling [appName:,modulename:myapp.jboss.ejb3,distinctname:myapp
    _ejb3] combination for invocation context org.jboss.ejb.client.EJBClientInvocationContext@10729e4
    18:07:50,699 INFO  [stdout] (http--127.0.0.1-8081-1)    at org.jboss.ejb.client.EJBClientContext.req
    #endpoint.name=client-endpoint
    #remote.connection.provider.create.options.org.xnio.Options.SSL_ENABLED=false
    remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
    #remote.connectionprovider.create.options.
    remote.connections=default
    reconnect.tasks.timeout=15000
    remote.connection.default.host=localhost
    remote.connection.default.port=4447
    #remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false
    remote.connection.default.connect.timeout=35000
    remote.connection.default.username=user1
    remote.connection.default.password=pass

  20. Apr 10, 2013

    Jboss5.1 Migration to JBoss7.1 Custom-JNDI-Handling

    Hello together,

    in our applications we used to define jndi-mappings in jboss.xml:
    <?xml version="1.0" encoding="UTF-8"?>
    <jboss>
    <enterprise-beans>
    <session>
    <ejb-name>ContractPortfolioProcessServiceBean</ejb-name>
    <jndi-name>com/fja/ipl/customer/ilis/contractportfolio/ContractPortfolioProcessService</jndi-name>
    </session>
    </enterprise-beans>
    </jboss>

    ithis jboss.xml was placed then in META-INF of that ejb-jar

    So it was easy to lookup for that bean like:

    public static ContractPortfolioProcessService lookupContractPortfolioProcessService()
    throws NamingException {
    final Context context = new InitialContext();
    return (ContractPortfolioProcessService ) context.lookup("com/fja/ipl/customer/ilis/contractportfolio/ContractPortfolioProcessService");
    }
    jndi.properties{
    #JBoss
    java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
    java.naming.provider.url=jnp://localhost:1099
    java.naming.factory.url.pkgs=org.jboss.namingrg.jnp.interfaces
    }

    How can it be made on JBOSS7?

    Due ejb3-spec in JBOSS7 they can also define jboss-ejb3.xml like this:
    <jboss:ejb-jar xmlns:jboss="http://www.jboss.com/xml/ns/javaee"
    xmlns="http://java.sun.com/xml/ns/javaee"
    xmlns:iiop="urn:iiop"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-ejb3-2_0.xsd
    http://java.sun.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-ejb3-spec-2_0.xsd
    urn:iiop jboss-ejb-iiop_1_0.xsd"
    version="3.1"
    impl-version="2.0">
    <enterprise-beans>
    <session>
    <ejb-name>CounterBean</ejb-name>
    <mapped-name>org/jboss/as/quickstarts/ejb/remote/stateful/CounterBean</mapped-name>
    </session>
    </enterprise-beans>

    <assembly-descriptor>
    <iiop:iiop>
    <ejb-name>CounterBean</ejb-name>
    <iiop:binding-name>org/jboss/as/quickstarts/ejb/remote/stateful/CounterBean</iiop:binding-name>
    </iiop:iiop>
    </assembly-descriptor>
    </jboss:ejb-jar>

    It deploys also errorless. But i did not find any dokumentation to lookup my ejb like in example above.

    Who can help me giving a hint in this case?

    How is the jndi.properties-Configuration would be in this case?

    1. Apr 10, 2013

      Jboss7 IIOP-Client

         
      Hello together,

      investigating "getting started" for Jboss7 i have an example for an IIOP-Configuration: jboss-as-quickstart-master\jts\application-component-2(https://github.com/jboss-jdf/jboss-as-quickstart)

      there i found an jboss-ejb3.xml with configuration:
      <?xml version="1.0" encoding="UTF-8"?>
      <jboss:ejb-jar xmlns:jboss="http://www.jboss.com/xml/ns/javaee"
      xmlns="http://java.sun.com/xml/ns/javaee"
      xmlns:iiop="urn:iiop"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-ejb3-2_0.xsd
      http://java.sun.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-ejb3-spec-2_0.xsd
      urn:iiop jboss-ejb-iiop_1_0.xsd"
      version="3.1"
      impl-version="2.0">
      <assembly-descriptor>
      <iiop:iiop>
      <ejb-name>CounterBean</ejb-name>
      <iiop:binding-name>org/jboss/as/quickstarts/ejb/remote/stateful/CounterBean</iiop:binding-name>
      </iiop:iiop>
      </assembly-descriptor>
      </jboss:ejb-jar>

      And the Code calling this EJB from a Container would be like this:
      @EJB(lookup = "corbaname:iiop:localhost:3628#org/jboss/as/quickstarts/ejb/remote/stateful/CounterBean")
      RemoteCounter counterBean;

      My Question is, how would be the jndi.properies or else for the Client like this?

      public static RemoteCounter lookupRemoteStatefulCounter() throws NamingException
      Unknown macro: { \ final Hashtable jndiProperties = new Hashtable(); \ jndiProperties.put(Context.URL_PKG_PREFIXES,"org.jboss.ejb.client.naming"); \ \ //jndiProperties.put(Context.INITIAL_CONTEXT_FACTORY,"org.jboss.naming.remote.client.InitialContextFactory"); \ // jndiProperties.put(Context.INITIAL_CONTEXT_FACTORY,"com.sun.jndi.cosnaming.CNCtxFactory"); \ //jndiProperties.put(Context.PROVIDER_URL,"corbaloc}



      My many attempts do not led to any success.

      I know there is another way to "lookup" an ejb on Jboss7 but i need it on this way. Please do not come with answer from the same sample-collection(f.e. ejb-remote).

  21. Jun 21, 2013

    Hello together, 

    I get the following error, whenn I run my ejb remote client:

    Jun 21, 2013 2:23:14 PM org.xnio.Xnio <clinit>
    INFO: XNIO Version 3.0.0.CR5
    Jun 21, 2013 2:23:14 PM org.xnio.nio.NioXnio <clinit>
    INFO: XNIO NIO Implementation Version 3.0.0.CR5
    Jun 21, 2013 2:23:14 PM org.jboss.remoting3.EndpointImpl <clinit>
    INFO: JBoss Remoting version 3.2.0.CR6
    Jun 21, 2013 2:23:14 PM org.jboss.ejb.client.remoting.VersionReceiver handleMessage
    INFO: Received server version 1 and marshalling strategies [river]
    Exception in thread "main" java.lang.NoSuchMethodError: org.jboss.remoting3.Channel.getOption(Lorg/xnio/Option;)Ljava/lang/Object; at org.jboss.ejb.client.remoting.ChannelAssociation.<init>(ChannelAssociation.java:118) at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.associate(RemotingConnectionEJBReceiver.java:158) at org.jboss.ejb.client.EJBClientContext.registerEJBReceiver(EJBClientContext.java:297) at org.jboss.ejb.client.EJBClientContext.registerEJBReceiver(EJBClientContext.java:252) at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.setupEJBReceivers(ConfigBasedEJBClientContextSelector.java:128) at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.<init>(ConfigBasedEJBClientContextSelector.java:78) at org.jboss.ejb.client.EJBClientContext.<clinit>(EJBClientContext.java:77) at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:120) at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:104) at $Proxy0.isValidSerialNumberRemoteMethod(Unknown Source) at ejb.kap01.remote.client.RemoteClient.main(RemoteClient.java:40)
    Jun 21, 2013 2:23:14 PM org.jboss.ejb.client.remoting.ChannelAssociation$ResponseReceiver handleMessage
    WARN: Unsupported message received with header 0xffffffff
    Jun 21, 2013 2:23:14 PM org.xnio.Xnio <clinit>

    INFO: XNIO Version 3.0.0.CR5

    Jun 21, 2013 2:23:14 PM org.xnio.nio.NioXnio <clinit>

    INFO: XNIO NIO Implementation Version 3.0.0.CR5

    Jun 21, 2013 2:23:14 PM org.jboss.remoting3.EndpointImpl <clinit>

    INFO: JBoss Remoting version 3.2.0.CR6

    Jun 21, 2013 2:23:14 PM org.jboss.ejb.client.remoting.VersionReceiver handleMessage

    INFO: Received server version 1 and marshalling strategies [river]

    Exception in thread "main" java.lang.NoSuchMethodError: org.jboss.remoting3.Channel.getOption(Lorg/xnio/Option;)Ljava/lang/Object;

    at org.jboss.ejb.client.remoting.ChannelAssociation.<init>(ChannelAssociation.java:118)

    at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.associate(RemotingConnectionEJBReceiver.java:158)

    at org.jboss.ejb.client.EJBClientContext.registerEJBReceiver(EJBClientContext.java:297)

    at org.jboss.ejb.client.EJBClientContext.registerEJBReceiver(EJBClientContext.java:252)

    at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.setupEJBReceivers(ConfigBasedEJBClientContextSelector.java:128)

    at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.<init>(ConfigBasedEJBClientContextSelector.java:78)

    at org.jboss.ejb.client.EJBClientContext.<clinit>(EJBClientContext.java:77)

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

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

    at $Proxy0.isValidSerialNumberRemoteMethod(Unknown Source)

    at ejb.kap01.remote.client.RemoteClient.main(RemoteClient.java:40)

    Jun 21, 2013 2:23:14 PM org.jboss.ejb.client.remoting.ChannelAssociation$ResponseReceiver handleMessage

    WARN: Unsupported message received with header 0xffffffff

    My jboss-ejb-client.properties file looks like this:

    remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
    remote.connections=default
    remote.connection.default.host=127.0.0.1
    remote.connection.default.port = 4447
    remote.connection.default.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false

    Can anyone help me to fix the problem?

  22. Aug 23, 2013

    Created a short article on how to disable the EJB remote security realm so that this example will work out of the box:

    Disable Remote EJB Security Realm

  23. Nov 25, 2013

    I would like to comment that the minimum required libraries for the client are the 10 packages of fedora, under /usr/share/java/, or under ejb-root-dir/modules/.

    From the highest level utility functions to the lowest level can be listed as follows,

    This is about the same number of dependency jar packs as EJB3.0 book's first exercise in its workbook.

    Also, for an actual remote machine to run the client, don't forget to run add_user.sh . 

    The above 10 packages combined size is about 1MB. The combo jboss-client.jar's size is about 3MB.

    So, 2/3 of the combo are for other kinds of works. And, yeah, for a client-server IP socket communication

    with interface oriented implementation, you need 1MB of code on top of java-se.