1. Overview
In this article, we’ll show how to integrate Spring and remote Enterprise Java Beans (EJB).
To do this, we’ll create some EJBs and the necessary remote interfaces, and then we’ll run them inside a JEE container. After that, we’ll start our Spring application and, using the remote interfaces, instantiate our beans so that they can execute remote calls.
If there is any doubt about what EJBs are or how they work, we already published an introductory article on the topic here.
2. EJB Setup
We’ll need to create our remote interfaces and our EJB implementations. To make them usable, we’ll also need a container to hold and manage beans.
2.1. EJB Remote Interfaces
Let’s start by defining two very simple beans — one stateless and one stateful.
We’ll begin with their interfaces:
@Remote
public interface HelloStatefulWorld {
int howManyTimes();
String getHelloWorld();
}
@Remote
public interface HelloStatelessWorld {
String getHelloWorld();
}
2.2. EJB Implementation
Now, let’s implement our remote EJB interfaces:
@Stateful(name = "HelloStatefulWorld")
public class HelloStatefulWorldBean implements HelloStatefulWorld {
private int howManyTimes = 0;
public int howManyTimes() {
return howManyTimes;
}
public String getHelloWorld() {
howManyTimes++;
return "Hello Stateful World";
}
}
@Stateless(name = "HelloStatelessWorld")
public class HelloStatelessWorldBean implements HelloStatelessWorld {
public String getHelloWorld() {
return "Hello Stateless World!";
}
}
If stateful and stateless beans sound unfamiliar, this intro article may come in handy.
2.3. EJB Container
We can run our code in any JEE container, but for practicality purposes, we’ll use Wildfly and the cargo Maven plugin to do the heavy lifting for us:
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<version>1.6.1</version>
<configuration>
<container>
<containerId>wildfly10x</containerId>
<zipUrlInstaller>
<url>
http://download.jboss.org/wildfly/10.1.0.Final/wildfly-10.1.0.Final.zip
</url>
</zipUrlInstaller>
</container>
<configuration>
<properties>
<cargo.hostname>127.0.0.1</cargo.hostname>
<cargo.jboss.configuration>standalone-full</cargo.jboss.configuration>
<cargo.jboss.management-http.port>9990</cargo.jboss.management-http.port>
<cargo.servlet.users>testUser:admin1234!</cargo.servlet.users>
</properties>
</configuration>
</configuration>
</plugin>
2.4. Running the EJBs
With these configured, we can run the container directly from the Maven command line:
mvn clean package cargo:run -Pwildfly-standalone
We now have a working instance of Wildfly hosting our beans. We can confirm this by the log lines:
java:global/ejb-remote-for-spring/HelloStatefulWorld!com.baeldung.ejb.tutorial.HelloStatefulWorld java:app/ejb-remote-for-spring/HelloStatefulWorld!com.baeldung.ejb.tutorial.HelloStatefulWorld java:module/HelloStatefulWorld!com.baeldung.ejb.tutorial.HelloStatefulWorld java:jboss/exported/ejb-remote-for-spring/HelloStatefulWorld!com.baeldung.ejb.tutorial.HelloStatefulWorld java:global/ejb-remote-for-spring/HelloStatefulWorld java:app/ejb-remote-for-spring/HelloStatefulWorld java:module/HelloStatefulWorld
java:global/ejb-remote-for-spring/HelloStatelessWorld!com.baeldung.ejb.tutorial.HelloStatelessWorld java:app/ejb-remote-for-spring/HelloStatelessWorld!com.baeldung.ejb.tutorial.HelloStatelessWorld java:module/HelloStatelessWorld!com.baeldung.ejb.tutorial.HelloStatelessWorld java:jboss/exported/ejb-remote-for-spring/HelloStatelessWorld!com.baeldung.ejb.tutorial.HelloStatelessWorld java:global/ejb-remote-for-spring/HelloStatelessWorld java:app/ejb-remote-for-spring/HelloStatelessWorld java:module/HelloStatelessWorld
3. Spring Setup
Now that we have our JEE container up and running, and our EJBs deployed, we can start our Spring application. We’ll use spring-boot-web to make it easier to test manually, but it isn’t mandatory for the remote call.
3.1. Maven Dependencies
To be able to connect to the remote EJBs, we’ll need the Wildfly EJB Client library and our remote interface:
<dependency>
<groupId>org.wildfly</groupId>
<artifactId>wildfly-ejb-client-bom</artifactId>
<version>10.1.0.Final</version>
<type>pom</type>
</dependency>
<dependency>
<groupId>com.baeldung.spring.ejb</groupId>
<artifactId>ejb-remote-for-spring</artifactId>
<version>1.0.1</version>
<type>ejb</type>
</dependency>
The last version of wildfly-ejb-client-bom can be found here.
3.2. Naming Strategy Context
With these dependencies in the classpath, we can instantiate a javax.naming.Context to do the lookup of our remote beans. We’ll create this as a Spring Bean so that we can autowire it when we need it:
@Bean
public Context context() throws NamingException {
Properties jndiProps = new Properties();
jndiProps.put("java.naming.factory.initial",
"org.jboss.naming.remote.client.InitialContextFactory");
jndiProps.put("jboss.naming.client.ejb.context", true);
jndiProps.put("java.naming.provider.url",
"http-remoting://localhost:8080");
return new InitialContext(jndiProps);
}
The properties are necessary to inform both the remote URL and the naming strategy context.
3.3. JNDI Pattern
Before we can wire our remote beans inside the Spring container, we’ll need to know how to reach them. For this, we’ll use their JNDI bindings. Let’s see the standard pattern for these bindings:
${appName}/${moduleName}/${distinctName}/${beanName}!${viewClassName}
Keep in mind that, since we deployed a simple jar instead of an ear and didn’t explicitly set up a name, we don’t have an appName and a distinctName. There are more details at our EJB Intro article in case something seems odd.
We’ll use this pattern to bind our remote beans to our Spring ones.
3.4. Building our Spring Beans
To reach our EJBs, we’ll use the aforementioned JNDI. Remember log lines that we used to check if our enterprise beans were deployed?
We’ll see that information in use now:
@Bean
public HelloStatelessWorld helloStatelessWorld(Context context)
throws NamingException {
return (HelloStatelessWorld)
context.lookup(this.getFullName(HelloStatelessWorld.class));
}
@Bean
public HelloStatefulWorld helloStatefulWorld(Context context)
throws NamingException {
return (HelloStatefulWorld)
context.lookup(this.getFullName(HelloStatefulWorld.class));
}
private String getFullName(Class classType) {
String moduleName = "ejb-remote-for-spring/";
String beanName = classType.getSimpleName();
String viewClassName = classType.getName();
return moduleName + beanName + "!" + viewClassName;
}
We need to be very careful about the correct full JNDI binding, or the context won’t be able to reach the remote EJB and create the necessary underlying infrastructure.
Keep in mind that the method lookup from Context will throw a NamingException in case it doesn’t find the bean you are requiring.
4. Integration
With everything in place, we can inject our beans in a controller, so we can test if the wiring is right:
@RestController
public class HomeEndpoint {
// ...
@GetMapping("/stateless")
public String getStateless() {
return helloStatelessWorld.getHelloWorld();
}
@GetMapping("/stateful")
public String getStateful() {
return helloStatefulWorld.getHelloWorld()
+ " called " + helloStatefulWorld.howManyTimes() + " times";
}
}
Let’s start our Spring server and check some logs. We’ll see the following line, indicating that everything is OK:
EJBCLIENT000013: Successful version handshake completed
Now, let’s test our stateless bean. We can try some curl commands to verify that they’re operating as expected:
curl http://localhost:8081/stateless Hello Stateless World!
And let’s check our stateful one:
curl http://localhost:8081/stateful Hello Stateful World called 1 times curl http://localhost:8081/stateful Hello Stateful World called 2 times
5. Conclusion
In this article, we learned how to integrate Spring to EJB and make remote calls to the JEE container. We created two remote EJB interfaces, and we were able to call those using Spring Beans in a transparent way.
Even though Spring is widely adopted, EJBs are still popular in enterprise environments, and in this quick example, we’ve shown that it’s possible to make use of both the distributed gains of JavaEE and the ease of use of Spring applications.
As always, the code can be found over on GitHub.