Java Reference
In-Depth Information
Creating a remote EJB client
Creating a remote EJB client for the WildFly application server is very similar to AS7. The
big difference can be noticed between AS6 and newer releases.
As a matter of fact, previous versions of WildFly (JBoss AS versions before 7.x) used the
JBoss naming project as the JNDI naming implementation, so developers are familiar with
jnp:// PROVIDER_URL
to communicate with the application server.
Starting with AS7, the JNP project is no longer used—neither on the server side nor on the
client side. The client side of the JNP project has now been replaced by the jboss-remote-
naming project. There were various reasons why the JNP client was replaced by the jboss-
remote-naming project. One of them was that the JNP project did not allow fine-grained se-
curity configurations while communicating with the JNDI server. The jboss-remote-naming
project is backed by the jboss-remoting project which allows much more and better control
over security.
Besides the new naming implementation in AS7 and WildFly, there is no longer any sup-
port to bind custom JNDI names to EJBs. So the beans are always bound to the spec's man-
dated
java:global
,
java:app
, and
java:module
namespaces. Therefore, setting
the JNDI name for the session bean element via an annotation or configuration file is no
longer supported.
So, what will be the JNDI name used to invoke a stateless session bean? Here it is:
ejb:<app-name>/<module-name>/<distinct-name>/
<bean-name>!<fully-qualified-classname-of-the-remote-interface>
A bit verbose, isn't it? However, the following table will help you get through it:
Element
Description
This is the enterprise application name (without
ear
), if your EJB has been
packed in an EAR
app-name
This is the module name (without
.jar
or
.war
), where your EJB has been
packed
module-name
distinct-name
Using this, you can optionally set a distinct name for each deployment unit
