Integration Guide for Spring and EJB

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 will run our application using a dedicated Wildlfy instance. This introductory article can come in handy if you want to set up your dedicated instance. You can then configure a profile to deploy the application to the installed Wildfly instance.

<profile>
 <id>wildfly-runtime</id>
 <plugin>
     <groupId>org.wildfly.plugins</groupId>
     <artifactId>wildfly-maven-plugin</artifactId>
     <version>1.1.0.Alpha5</version>
     <configuration>
                <hostname>127.0.0.1</hostname>
                <port>9990</port>
                <username>9990</username>
                <password>admin1234!</password>
                <filename>${project.build.finalName}.jar</filename>
     </configuration>
 </plugin>
</profile>

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

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 Jakarta EE and the ease of use of Spring applications.