Introduction

EJB 3.0 was the release that made Enterprise JavaBeans practical for many teams again by replacing large XML-heavy patterns with annotations and plain Java classes. GlassFish matters here because it was the Java EE reference server, so it remains a useful environment for understanding how EJB 3.0 components are packaged, deployed, and injected.

What EJB 3.0 Simplified

Older EJB versions required home interfaces, remote interfaces, deployment descriptors, and a lot of container-specific ceremony. EJB 3.0 reduced that friction with:

• annotation-based bean definitions
• dependency injection
• POJO-style programming
• container-managed transactions
• simpler local and remote access

That is why many examples from the GlassFish era look much closer to modern Java than EJB 2.x code.

A Basic Stateless Session Bean

The most common EJB 3.0 example is a stateless session bean. It represents business logic with no conversational state tied to a specific client.

1package com.example.ejb;
2
3import javax.ejb.Local;
4
5@Local
6public interface GreetingService {
7    String greet(String name);
8}

1package com.example.ejb;
2
3import javax.ejb.Stateless;
4
5@Stateless
6public class GreetingServiceBean implements GreetingService {
7    @Override
8    public String greet(String name) {
9        return "Hello, " + name;
10    }
11}

GlassFish detects the annotations during deployment and registers the bean automatically.

Injecting the Bean Into Another Component

One of the main benefits of EJB 3.0 is that you usually consume beans through injection rather than manual lookups.

1package com.example.web;
2
3import com.example.ejb.GreetingService;
4import javax.ejb.EJB;
5import java.io.IOException;
6import javax.servlet.ServletException;
7import javax.servlet.annotation.WebServlet;
8import javax.servlet.http.HttpServlet;
9import javax.servlet.http.HttpServletRequest;
10import javax.servlet.http.HttpServletResponse;
11
12@WebServlet("/hello")
13public class HelloServlet extends HttpServlet {
14
15    @EJB
16    private GreetingService greetingService;
17
18    @Override
19    protected void doGet(HttpServletRequest req, HttpServletResponse resp)
20            throws ServletException, IOException {
21        resp.getWriter().println(greetingService.greet("GlassFish"));
22    }
23}

That injection point is resolved by the container when the application is deployed.

Packaging and Deploying on GlassFish

For a simple application, you typically package the EJB and web layer in a WAR or EAR and deploy it to GlassFish. If you are using Maven, the build often looks familiar:

1<dependency>
2  <groupId>javax</groupId>
3  <artifactId>javaee-api</artifactId>
4  <version>6.0</version>
5  <scope>provided</scope>
6</dependency>

The provided scope matters because GlassFish already supplies the Java EE APIs at runtime.

Once packaged, deployment can be done from the admin console or command line:

asadmin deploy target/app.war

After deployment, GlassFish manages lifecycle, pooling, transactions, security integration, and injection.

Transactions and Container Services

A major reason to use EJB was never just object lookup. It was access to container services with minimal code.

For example, a method on a stateless bean can run inside a transaction automatically:

1package com.example.ejb;
2
3import javax.ejb.Stateless;
4import javax.ejb.TransactionAttribute;
5import javax.ejb.TransactionAttributeType;
6
7@Stateless
8public class PaymentServiceBean {
9
10    @TransactionAttribute(TransactionAttributeType.REQUIRED)
11    public void chargeAccount(String accountId, double amount) {
12        // business logic and persistence work happen inside a container-managed transaction
13    }
14}

In many cases, the container default is already enough, but explicit annotations make the intent clear.

Common Pitfalls

The most common mistake is packaging the Java EE API into the application instead of marking it as provided. Doing so can create classloading conflicts on GlassFish.

Another issue is confusing local and remote interfaces. If your client is inside the same application, a local interface is usually the right choice and simpler to configure.

A third pitfall is treating EJB as just another object with new. Container-managed features such as transactions and injection only work when the bean is created and invoked through the container.

Finally, many old tutorials mix versions of Java EE, GlassFish, and EJB syntax. Keep the example internally consistent so the deployment model matches the server you are actually using.

Summary

• EJB 3.0 made enterprise components much simpler through annotations and injection.
• GlassFish is a natural server for learning EJB because it was the Java EE reference implementation.
• Stateless session beans are the standard entry point for business logic.
• Use container injection and container lifecycle instead of constructing beans manually.
• Keep dependencies and packaging aligned with the GlassFish version you deploy to.