Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
ejb Project
The final subproject in this example contains all the EJBs that will be used. Because I am quite fond of XDoclet, this subproject will utilize XDoclet during its build process to simply the coding of the EJB layer. In this subproject, I created one entity bean in the com.zarrastudios.ejb package:
package com.zarrastudios.ejb;
import javax.ejb.CreateException;
import javax.ejb.EntityBean;
import org.apache.log4j.Logger;
/**
* @ejb.bean jndi-name="com/zarrastudios/remote/Example"
* local-jndi-name="com/zarrastudios/local/Example"
* primkey-field="ID"
* cmp-version="2.x"
*
* @ejb.interface remote-class="com.zarrastudios.ejb.ExampleRemote"
* local-class="com.zarrastudios.ejb.ExampleLocal"
*
* @ejb.home remote-class="com.zarrastudios.ejb.ExampleRemoteHome"
* local-class="com.zarrastudios.ejb.ExampleLocalHome"
*
*/
public abstract class ExampleBean implements EntityBean {
private static final Logger log = Logger.getLogger(ExampleBean.class);
/**
* @ejb.create-method
*/
public String ejbCreate() throws CreateException {
log.debug("Example Bean create called");
setID(ExampleUtil.generateGUID(this));
return null;
}
/**
* @ejb.interface-method
* @ejb.persistence
*/
public abstract String getID();
public abstract void setID(String s);
/**
* @ejb.interface-method
* @ejb.persistence
*/
public abstract String getName();
/**
* @ejb.interface-method
*/
public abstract void setName(String s);
/**
* @ejb.interface-method
* @ejb.persistence
*/
public abstract String getValue();
/**
* @ejb.interface-method
*/
public abstract void setValue(String s);
}
Those familiar with XDoclet will see that this is a simple Entity bean with three fields: name, value, and id.
The project.xml file for this subproject is as follows:
<project>
<extend>../common/project.xml</extend>
<name>J2EE Application</name>
<artifactId>ejb</artifactId>
<shortDescription>J2EE back-end for example application</shortDescription>
<dependencies>
<dependency>
<groupId>jboss</groupId>
<artifactId>jboss-j2ee</artifactId>
<version>3.2.1</version>
</dependency>
<dependency>
<groupId>${pom.groupId}</groupId>
<artifactId>util</artifactId>
<version>${pom.currentVersion}</version>
</dependency>
</dependencies>
</project>
This project.xml has one internal dependency: the util project. It also has one external dependency: JBoss' j2ee implementation. If this were a completely functional application, the web project would also have this dependency.
The maven.xml file for this subproject is as follows:
<project default="example:build"> <preGoal name="java:compile"> <attainGoal name="xdoclet:ejbdoclet"/> </preGoal> <goal name="example:build" prereqs="ejb:install"/> </project>
This maven.xml has some additional work that the others did not. Specifically, I defined a pregoal that will be executed prior to the compile phase of the build. This pregoal is an instruction to the xdoclet:ejbdoclet goal and tells Maven to run xdoclet prior to compiling the source files. This process will produce all the home classes and the interfaces needed by this subproject.
The project.properties file for this subproject has some additional settings as well. Because I prefer to use XDoclet's GUID generation code, I need to tell XDoclet to include it during the source code generation. Therefore, the project.properties file is as follows:
maven.xdoclet.ejbdoclet.utilobject.0.includeGUID=true
Assuming that everything was entered correctly, this subproject is now ready to be built. Because we previously built the util subproject, it is sitting in the local repository and can be referenced now. Executing maven in the ejb directory will cause the XDoclet source files to be generated, the source code to be compiled and the ejb-jar.xml file to be generated. The results of this will be wrapped up in a jar file and installed in the local repository.
There is one item missing from this subproject: the generation of the JBoss-specific configuration files by XDoclet. This is because of an issue with the XDoclet-Maven plugin at the time of this writing. Although none of the app server modules is functioning properly, a bug report has been filed, and the problem is expected to be resolved soon. After it is resolved, a simple additional dependency will cause the app server configuration files to be generated.