Java EE 7 SDK 

Samples Main Page

The WAR-based EJB Sample Application

This is a simple EJB 3.2 application that shows the use of WAR-based packaging, the no-interface local view, singleton session beans, and startup/shutdown callbacks.

Description

The application is composed of a servlet, a singleton session bean, and a stateless session bean. Each session bean exposes a no-interface view. The singleton defines a callback that is called by the container during application initialization. Both the servlet and stateless bean use the singleton to access common application configuration information. When the servlet is accessed, it invokes the session beans and prints some messages containing the return values.

The entire application is packaged within a .war file, without any .xml files.

No-interface View

Each session bean exposes a no-interface local view. This client view has the same semantics as the EJB 3.1 local business interface, except that it does not require a separate interface. All public methods of the bean class are automatically exposed to the caller. By default, any session bean that has an empty implements clause and does not define any other local/remote client views exposes a no-interface client view:

@Stateless
public class HelloBean {   

	public String sayHello() {
		String message = propertiesBean.getProperty("hello.message");
		return message;
	}
}
        

A client of the no-interface view always acquires an EJB reference, either through injection or JNDI lookup. The Java type of the EJB reference is the bean class. The client never uses the new() operator to explicitly instantiate the bean class:

	@EJB
	private HelloBean helloBean;
	
	...
	
	String helloMsg = helloBean.sayHello();
				

Singleton Bean

A singleton bean is a new kind of session bean component that is guaranteed to be instantiated once per application in a particular JVM. A singleton bean is defined using the @Singleton component-defining annotation.

By default, the container decides when to instantiate the singleton bean. However, the developer can force the container to instantiate the singleton bean during application initialization by using the @Startup annotation. This allows the bean to define a @PostConstruct method that is guaranteed to be called during startup time. In addition, regardless of eager vs. lazy instantiation, any singleton @PostDestroy method is guaranteed to be called when the application is shutting down.

@Singleton
@Startup
public class PropertiesBean {
  
	@PostConstruct
	private void startup() { ... }
  
	@PreDestroy
	private void shutdown() { ... }

	...  
}
			

Deployment Descriptor

No deployment descriptors are needed, even for the servlet. All metadata is either defaulted or specified using annotations.

Packaging

The entire application is packaged in a single .war file. The EJB 3.2 specification allows any enterprise bean classes to be packaged directly in WEB-INF/classes (or in a .jar in WEB-INF/lib), just like other .war files.

Key Features

This sample demonstrates the following key features:

Building, Deploying, and Running the Application

Perform the following steps to build, deploy, and run the application:

  1. Set up your build environment and configure the application server with which the build system has to work by following the common build instructions.
  2. app_dir is the sample application base directory: samples_install_dir/javaee7/ejb/ejb32-war.
  3. Change directory to app_dir.
  4. Build, deploy, and run the sample application using the run outcome.

    mvn clean verify cargo:run

  5. After deployment, the test servlet can be accessed at http://<host>:<http-port>/ejb32-war. The default location is http://localhost:8080/ejb32-war.
  6. Use the clean outcome to undeploy the sample application and to remove the temporary directories such as target.

    mvn clean

Troubleshooting

If you have problems when running the application, refer to the troubleshooting document.



Copyright © 1997-2013 Oracle and/or its affiliates. All rights reserved.