Standalone Application Invocation into a Remote Session EJB: Difference between revisions
No edit summary |
No edit summary |
||
Line 17: | Line 17: | ||
=Business Interface Type Access= | =Business Interface Type Access= | ||
The calling application needs the business interface type to make the call, so the classes related to the business interface will have to be | The calling application needs the business interface type to make the call, so the classes related to the business interface will have to be made accessible on the standalone application's classpath. Since those classes are also needed in the EJB deployment unit, the best strategy is to develop those as part of shared "common-types" Maven module, and pull its artifact in the EJB JAR, then makes accessible on the standalone application's classpath. The example linked above showcases this approach. A Maven "recipe" to include some dependencies in a simple JAR artifact is described here: [[Maven Include Dependencies in JAR Artifact|Include Dependencies in JAR Artifact]]. | ||
=EJB Lookup= | =EJB Lookup= | ||
==Configure EJB Client Context | ==Configure EJB Client Context in jboss-ejb-client.properties== | ||
The | The standalone application needs a way to look up the EJB reference that has been deployed on a remote JBoss instance. This is done internally by using a JBoss-specific mechanism named [[EJB_Concepts#EJB_Client_Context|EJB client context]]. In order to use the EJB client context that knows how to invoke into the remote JBoss instance, the standalone application must have access to a jboss-ejb-client.properties on its classpath. | ||
<pre> | <pre> | ||
</pre> | </pre> | ||
More details about jboss-ejb-client.properties are available here: | |||
{{Internal|Jboss-ejb-client.properties|jboss-ejb-client.properties}} | |||
{{Internal|Jboss-ejb-client. | |||
More details about the EJB client context are available here: | More details about the EJB client context are available here: | ||
Line 85: | Line 73: | ||
} | } | ||
</pre> | </pre> | ||
=EJB Invocation= | =EJB Invocation= |
Revision as of 00:35, 25 March 2017
Internal
Overview
This example describes how a standalone Java application looks up a remote EJB and makes a remote invocation.
GitHub Example
The Business Interface Must be Market as @Remote
The business interface must be marked with the @Remote annotation, otherwise the EJB won't be accessible remotely. If the business interface is not annotated with @Remote, the JNDI lookup on the client side, even if using the correct EJB client context, will fail to locate the EJB.
Business Interface Type Access
The calling application needs the business interface type to make the call, so the classes related to the business interface will have to be made accessible on the standalone application's classpath. Since those classes are also needed in the EJB deployment unit, the best strategy is to develop those as part of shared "common-types" Maven module, and pull its artifact in the EJB JAR, then makes accessible on the standalone application's classpath. The example linked above showcases this approach. A Maven "recipe" to include some dependencies in a simple JAR artifact is described here: Include Dependencies in JAR Artifact.
EJB Lookup
Configure EJB Client Context in jboss-ejb-client.properties
The standalone application needs a way to look up the EJB reference that has been deployed on a remote JBoss instance. This is done internally by using a JBoss-specific mechanism named EJB client context. In order to use the EJB client context that knows how to invoke into the remote JBoss instance, the standalone application must have access to a jboss-ejb-client.properties on its classpath.
More details about jboss-ejb-client.properties are available here:
More details about the EJB client context are available here:
Use a Specific JNDI Name
Use a JNDI name that complies with the following pattern:
ejb:[/<application-name>/]<module-name>/<bean-name>!<view-class>
Example:
ejb:/stateless-ejb-example/SimpleStatelessBean!io.novaordis.playground.jee.ejb.stateless.SimpleStateless
The "ejb:" name space is essential, it is what seems to be engaging the correct EJB client context, if "java:global" is used, the look up will fail.
The !<view-class> part is also essential, if not used, the JNDI lookup will return an org.jboss.ejb.client.naming.ejb.EjbNamingContext instance, instead of a business interface type.
JNDI Lookup Code
The code that does the JNDI lookup is similar to:
SimpleStateless bean = null; ... try { InitialContext ic = new InitialContext(); SimpleStateless bean = (SimpleStateless)ic.lookup( "ejb:/stateless-ejb-example/SimpleStatelessBean!io.novaordis.playground.jee.ejb.stateless.SimpleStateless"); } catch(Exception e) { ... }
EJB Invocation
Once the EJB reference is obtained from JNDI, business interface methods can be called on its reference:
... bean.methodOne("something from servlet");