• Setting up a development environment

• Customization

• Java EE programming modules

• Clustering

• Security

All these features will be explored by developing sample and intuitive applications built using the friendly interface of Eclipse and JBoss Tools.

What This Book Covers

Chapter 1: Installing Core Components covers the installation of the key components that will be needed throughout the rest of the book. The installation process will be completed by using intuitive wizards that will lead even inexperienced users through it.

Chapter 2: What’s New in JBoss AS 5.0 introduces the reader to the most significant changes brought by release 5.0 of the application server. The new server directory tree is analyzed in detail and possible variants in the server configuration are discussed in the latter part of this chapter.

Chapter 3: Customizing JBoss Services discusses the core configuration of the application server. The highlights of it include an introduction to JBoss AS monitoring services, the inner details about JBoss thread pool, how to configure logging services, and a detailed description of the transaction and Datasource service.

Chapter 4: Developing EJB 3 Session Bean introduces the reader to some concrete Java EE programming examples developed on JBoss AS 5. The focus of this chapter is on EJB 3 session Beans, including a section about their configuration for optimal results.

Chapter 5: Developing JPA Entities covers the development of an example based on the Java Persistence API (JPA). Here, we introduce an enterprise application named the Appstore, which will be a central theme of this book.

Chapter 6: Creating a Web Application is about developing and configuring web applications on JBoss AS 5.0 using the JSF cutting-edge technology. In the first part of this chapter we will enhance the Appstore Enterpirse application by adding a web layer to
it. In the latter part, we explain in detail how to properly configure JBoss Web Server.

Chapter 7: Developing Applications with JBoss Messaging Service discusses JBoss Messaging provider by giving a short introduction to the new messaging system. The chapter then helps us set up some proof of concept programming examples.

Chapter 8: Developing Applications with JBoss and Hibernate covers the de facto standard object relational mapping tool, Hibernate, showing how to quickly set up a Hibernate project using the facilities provided by the JBoss tools interface.

Chapter 9: Managing JBoss AS covers the Java Management Extension (JMX), which still plays a vital role in the application server infrastructure. The chapter includes many examples that show how to write traditional MBeans services and the new POJO Services.

Chapter 10: Developing Applications with JBoss Web Services focuses on the JBoss Web Service implementation, JBossWS, showing how to create, deploy, and test Web Services on JBoss AS along with some advanced concepts such as Handler chains and SOAP debugging.

Chapter 11: Clustering JBoss AS covers the facts about JBoss AS clustering configuration, moving from cluster basics to detailed configuration of the individual services of the application server.

Chapter 12: Developing a Clustered Application continues the journey in the clustering arena by adding some concrete examples based on the abstract concepts covered in the earlier chapter.

Chapter 13: JBoss AS Security provides a systematic guide to JBoss security framework and the cryptographic interfaces available in the Java EE framework. This supplies the basis for concrete examples, which are delivered in the next chapter.

Chapter 14: Securing JBoss AS Applications continues the in-depth exploration of the JBoss security framework, adding concrete programming examples applied on the EJB and Web Services technologies.

Developing Applications with JBoss and Hibernate

	<i>Hibernation is a state of regulated hypothermia undergone by some animals to
	conserve energy during the winter</i>. – Wikipedia

In this chapter, we will introduce Hibernate, which is the de facto standard object-relational mapping framework for Java applications. The Hibernate galaxy is quite large and needs a book of its own to be fully explored. Our mission will be to take over one sector of this galaxy, especially where Hibernate applications are managed by JBoss AS.

In this chapter, we will cover the following topics:

• A short introduction to Hibernate

• Setting up our proof of concept for the Hibernate project

• Reverse engineering a database schema into Hibernate POJOs and mapping files

• Deploying the application to JBoss AS

• Comparing the Hibernate technology with EJB 3 persistence (JPA)

Introducing Hibernate

Hibernate provides a bridge between the database and the application by persisting application objects in the database, rather than requiring the developer to write and maintain lots of code to store and retrieve objects.

The main configuration file, hibernate.cfg.xml, specifies how Hibernate obtains database connections, either from a JNDI DataSource or from a JDBC connection pool. Additionally, the configuration file defines the persistent classes, which are backed by mapping definition files.

This is a sample hibernate.cfg.xml configuration file that is used to handle connections to a MySQL database, mapping the com.sample.MySample class.

	<hibernate-configuration>
		<session-factory>
			<property name="connection.username">user</property>
			<property name="connection.password">password</property>
			<property name="connection.url">
				jdbc:mysql://localhost/database
			</property>
			<property name="connection.driver_class">
				com.mysql.jdbc.Driver
			</property>
			<property name="dialect">
				org.hibernate.dialect.MySQLDialect
			</property>
			<mapping resource="com/sample/MyClass.hbm.xml"/>
		</session-factory>
	</hibernate-configuration>

From our point of view, it is important to know that Hibernate applications can coexist in both the managed environment and the non-managed environment. An application server is a typical example of a managed environment that provides services to hosting applications, such as connection pooling and transaction.

On the other hand, a non-managed application refers to standalone applications, such as Swing Java clients that typically lack any built-in service.

In this chapter, we will focus on managed environment applications, installed on JBoss Application Server. You will not need to download any library to your JBoss installation. As a matter of fact, JBoss persistence layer is designed around Hibernate API, so it already contains all the core libraries.

Creating a Hibernate application

You can choose different strategies for building a Hibernate application. For example, you could start building Java classes and map files from scratch, and then let Hibernate generate the database schema accordingly. You can also start from a database schema
and reverse engineer it into Java classes and Hibernate mapping files. We will choose the latter option, which is also the fastest. Here’s an overview of our application.

In this example, we will design an employee agenda divided into departments. The persistence model will be developed with Hibernate, using the reverse engineering facet of JBoss tools. We will then need an interface for recording our employees and
departments, and to query them as well.

The web interface will be developed using a simple Model-View-Controller (MVC) pattern and basic JSP 2.0 and servlet features.

The overall architecture of this system resembles the AppStore application that has been used to introduce JPA. As a matter of fact, this example can be used to compare the two persistence models and to decide which option best suits your project needs. We have added a short section at the end of this example to stress a few important points about this choice.

Setting up the database schema

As our first step, we are going to create the necessary tables for our example. Launch a MySQL client and issue the following DDL:

	CREATE schema hibernate;
	GRANT ALL PRIVILEGES ON hibernate.* TO 'jboss'@'localhost' WITH GRANT
	OPTION;
	CREATE TABLE `hibernate`.`department` (
		`department_id` INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
		`department_name` VARCHAR(45) NOT NULL,
		PRIMARY KEY (`department_id`)
	)
	ENGINE = InnoDB;
	CREATE TABLE `hibernate`.`employee` (
		`employee_id` INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
		`employee_name` VARCHAR(45) NOT NULL,
		`employee_salary` INTEGER UNSIGNED NOT NULL,
		`employee_department_id` INTEGER UNSIGNED NOT NULL,
		PRIMARY KEY (`employee_id`),
		CONSTRAINT `FK_employee_1` FOREIGN KEY `FK_employee_1` (`employee_
	department_id`)
		REFERENCES `department` (`department_id`)
		ON DELETE CASCADE
		ON UPDATE CASCADE
	)
	ENGINE = InnoDB;

With the first Data Definition Language (DDL) command, we have created a schema named Hibernate that will be used to store our tables. Then, we have assigned the necessary privileges on the Hibernate schema to the user jboss (created in Chapter 5, Developing JPA Entities).

Finally, we created a table named department that contains the list of company units, and another table named employee that contains the list of workers. The employee table references the department with a foreign key constraint.

A new Eclipse project

Now start Eclipse. You don’t have a specific project for Hibernate applications, so a utility project (that simply packs the classes in an archive) will be enough. You can reach this option from the menu by going to New | Other | Java EE | Utility Project.

Now, we are going to unleash the full potential of Hibernate tools. Select from the menu New | Other | Hibernate | Hibernate Configuration File. The Hibernate configuration contains all of the details for wiring your application to the database. You will be asked for the name and the parent folder of the configuration file. Accept the default hibernate.cfg.xml at the root of your project.

One important selection is the Type option that lets you choose between the Core hibernate configuration (Java classes backed by mapping files), Annotations, or even JPA annotations. We will leave the selected Core option.

Before clicking Finish, select MySQL (InnoDB) as Database dialect in the Options tab. No other changes are required.

Reversing your schema into Java classes

The next move will be reversing our database schema into Java classes and mapping files. This powerful feature is available from the menu: File | New | Hibernate |Hibernate Reverse Engineering file. You can place this file in a convenient location for your project and choose a name for it. The default name proposed is hibernate.reveng.xml, which looks rather the tile of another fiction movie from G. Lucas.

	<hibernate-reverse-engineering>
		<table-filter match-catalog="hibernate" match-name="department"/>
		<table-filter match-catalog="hibernate" match-name="employee"/>
	</hibernate-reverse-engineering>

If you are smart at noticing variations, you might have discovered a new icon in your toolbar. This is your gateway to the reverse engineering process. (Notice: this icon is visible only in the Hibernate Perspective, you will not be able to find it anywhere else.)

Just below, you will find the checkbox Reverse engineer from JDBC Connection. If enabled, the tools will reverse engineer the available database using the connection information in the selected Hibernate Console configuration. Check this option and enter the package name for the generated classes, which will be com.packtpub. hibernate. Leave the other text fields to the defaults and move to the tab Exporters.

In the upper area of the dialog, you will notice an interesting checkbox named Generate EJB 3 annotations. We will return to this useful option later. At the moment, what we need is just to check the Domain code and Hibernate XML Mappings options, which will generate the Java POJOs and mapping files respectively.

It took a bit of time to complete all of these steps; however, now your Java classes and configuration files are handy and waiting to be packaged.

Adding Hibernate configuration to your project

The advantage of embedding the Hibernate application in JBoss AS is that you can expose Hibernate SessionFactory through a JN DI tree and modify its configuration at runtime.

This is indeed a great configuration advantage; before the new release of JBoss AS, you had to delegate to an MBean the creation of the Hibernate SessionFactory and its exposure through JNDI.

For example, if you wanted to configure a SessionFactory at the naming context hibernate/SessionFactory, you would have to package your Hibernate application with a file named xxx-service.xml in the META-INF folder. Here’s a sample of it:

	<server>
		<mbean code="org.jboss.hibernate.jmx.Hibernate"
			name="jboss.har:service=Hibernate">
			<attribute name="DatasourceName">java:/ MySqlDS</attribute>
			<attribute name="Dialect">
				org.hibernate.dialect.MySQLDialect
			</attribute>
			<attribute name="SessionFactoryName">
				java:/hibernate/SessionFactory
			</attribute>
			<attribute name="CacheProviderClass">
				org.hibernate.cache.HashtableCacheProvider
			</attribute>
		</mbean>
	</server>

This configur ation is still valid for pre 5.0 releases of JBoss AS. With the introduction of the new Virtual Deployment Framework (VDF), you now have to provide your SessionFactory configuration using the Hibernate XML schema. For example, if you want to link your SessionFactory to your MySQL database, you have to add the following service-hibernate.xml. (Be aware, the suffix is -hibernate.xml and not –service.xml.)

	<hibernate-configuration xmlns="urn:jboss:hibernate-deployer:1.0">
		<session-factory name="java:/hibernate/SessionFactory"
			bean="jboss.test.har:service=Hibernate,
			testcase=TimersUnitTestCase">
			<property name="datasourceName">java:/MySqlDS</property>
			<property name="dialect">
				org.hibernate.dialect.MySQLDialect
			</property>
			<depends>jboss:service=Naming</depends>
			<depends>jboss:service=TransactionManager</depends>
		</session-factory>
	</hibernate-configuration>

The preceding configuration file needs to be stored in the META-INF folder of your Hibernate archive (HAR) file. The structure of the updated project from the Package Explorer is as shown in the following snapshot:

Adding a web client to your project

There are seve ral ways to test our Hibernate application. The simplest of all is adding a web application, which is packaged in an Enterprise application along with the Hibernate application. Create a new dynamic web project named HibernateWeb.

The first step, before adding servlets and JSPs is linking the HibernateProject libraries to your web application, otherwise, you will not be able to reference the Hibernate POJOs. Right-click on your project and select Properties. Reach the Java Build Path option and select the tab Projects. From there add HibernateProject.

In the following snippet, you can see the core section of the servlet. Here, we will not detail the Controller logic, which is straightforward if you have some rudiments of the MVC pattern; rather we want to highlight the most interesting part of it, which is how to query and persist Hibernate objects.

	public class HibernateServlet extends HttpServlet {
		private SessionFactory getSessionFactory() {
			return (SessionFactory)getServletContext().
			getAttribute("sessionFactory");
		}
		public void init() { [1]
			if (getSessionFactory() != null) {
				return;
			}
			InitialContext ctx;
			try {
				ctx = new InitialContext();
				<b>factory = (SessionFactory)ctx.
					lookup("java:/hibernate/SessionFactory");
				getServletContext().setAttribute("sessionFactory", factory);</b>
			}
			catch (NamingException e) {
				e.printStackTrace();
			}
		}
		private String saveEmployee(HttpServletRequest request) {
			Session hsession=null;
			String name=request.getParameter("name");
			String salary=request.getParameter("salary");
			String departmentId=request.getParameter("departmentId");
			try {
				hsession = getSessionFactory().openSession();
				hsession.beginTransaction();
				<b>Query query = hsession.createQuery("from Department d where
					d.departmentId = :departmentId"); [2]</b>
				query.setInteger("departmentId", new Integer(departmentId));
				Department dep = (Department) query.uniqueResult();
				Employee emp = new Employee();
				emp.setDepartment(dep);
				emp.setEmployeeName(name);
				emp.setEmployeeSalary(Integer.parseInt(salary));
				<b>hsession.save(emp); [3]</b>
				hsession.getTransaction().commit();
			}
			catch (Exception e) {
				// TODO Auto-generated catch block e.printStackTrace();
				hsession.getTransaction().rollback();
			}
			finally {
				if (hsession.isOpen())
				hsession.close();
			}
			return employeeList(request);
		}
		private String employeeList(HttpServletRequest request) {
			Session hsession=null;
			Department dep;
			try {
				hsession = getSessionFactory().openSession();
				<b>Query query = hsession.createQuery("select p from Employee p
					join fetch p.department c"); [4]</b>
				List <Employee>list = query.list();
				request.setAttribute("employee", list);
			}
			catch (Exception e) {
				e.printStackTrace();
			}
			finally {
				if (hsession.isOpen())
				hsession.close();
			}
			return "/listEmployees.jsp";
		}
		private String saveDepartment(HttpServletRequest request) {
			String depName=request.getParameter("depName");
			Session hsession=null;
			Department dep;
			try {
				hsession = getSessionFactory().openSession();
				hsession.beginTransaction();
				dep = new Department();
				dep.setDepartmentName(depName);
				<b>hsession.save(dep); [5]</b>
				hsession.getTransaction().commit();
			}
			catch (Exception e) {
				// TODO Auto-generated catch block
				e.printStackTrace();
				hsession.getTransaction().rollback();
			}
			finally {
				if (hsession.isOpen())
				hsession.close();
			}
			return employeeList(request);
		}
	}

As you can see from the preceding code, we recover the SessionFactory from the JNDI tree in the init() [1] method of the servlet. Instances of SessionFactory are thread-safe and typically shared throughout an application, so we store it in the ServletContext and share it among all servlet instances.

The SessionFactory is subsequently used to start a Hibernate session, which is not thread-safe and should only be used for a single transaction or unit of work in an application.

In order to store our Employee, in the saveEmployee method, we first retrieve the corresponding Department from our schema [2], and finally the Employee is saved [3] and the transaction is committed.

The list of employees is fetched by the employeeList method. Notice we are using a join fetch statement to retrieve all the employees [4], which will be routed to the listEmployees.jsp view. Why? The answer is that with the default fetch mode (Lazy), once the Hibernate session is closed, the client will not be able to navigate through the department field of the Employee. The common solution to this issue is switching to the EAGER fetch mode that reads the related fields (in our case department) in memory, as soon as we query the Employee table.

You have more than one option to achieve this. One possible solution, if you don’t want to change the default fetch mode for the Employee table, is to build an ad hoc query that forces Hibernate to read also those fields that are in relation with the Employee table.

	"select p from Employee p join fetch p.department c"

If you prefer to use the XML class files to configure the fetch mode, you can also change the lazy=”true” attribute in the employee-department relationship.

The last method, saveDepartment [5] takes care to persist a new Department in the corresponding table. We complete our excursus on the web tier with the listEmployees.jsp that is used to display a tabular view of the employees:

	<b><%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %></b>
	<html>
		<script language="JavaScript">
			function doSubmit(url) {
				document.module.action = url;
				document.module.submit();
			}
		</script>
		<body>
			<table border="1">
				<tr>
					<th>Name</th>
					<th>Salary</th> <TH>department</th>
				</tr>
				<b><c:forEach items="${employee}" var="emp">
					<tr>
						<td> <c:out value="${emp.employeeName}"/> </td>
						<td> <c:out value="${emp.employeeSalary}"/></td>
						<td> <c:out value="${emp.department.departmentName}"/></td>
					</tr>
				</c:forEach></b>
			</table>
			<form name="module" method="POST">
				<input type="button" value ="New Employee"
					onClick="doSubmit('actionServlet?op=newEmployee')">
				<input type="button" value ="New Department"
					onClick="doSubmit('actionServlet?op=newDepartment')">
			</form>
		</body>
	</html>

This page uses JSP 2.0 Expression Language (EL) to iterate through the list of employees, as highlighted in the last code snippet. We have also highlighted the taglib directive, at the beginning of the page. This directive will be used to resolve the JSTL core set of libraries that ships with JBoss AS in the server/xxx/deploy/ jbossweb.sar/jstl.jar library. (Eclipse does not contain references to this library when you create a web project; you have to add jstl.jar to your build path, otherwise Eclipse will mark it as an error. However, that’s only a visual annoyance because the JBoss web container has got everything it needs to run JSTL.)

The complete web application is available on the Packtpub website (http://www.packtpub.com) and includes two additional JSPs for entering the employee (newEmployee.jsp) and department (newDepartment.jsp) data, plus one placeholder index.jsp that merely forwards to the HibernateServlet.

Packaging and deploying the application

Your enterprise application is complete. We need to package it in an EAR archive so that the web application will be able to interact with the Hibernate POJOs. Create a new Enterprise Application project from the Java EE folder. You will be prompted to select the projects that will be included as modules. Select both the HibernateProject and the web application HibernateWeb.

As HAR archives are not Java EE standard components, you have to declare it in a JBoss AS-specific configuration file named jboss-app.xml that sits in the META-INF folder of our EAR.

	<!DOCTYPE jboss-app PUBLIC "-//JBoss//DTD J2EE Application 1.5//EN"
		"http://www.jboss.org/j2ee/dtd/jboss-app_5_0.dtd">
		<jboss-app>
			<module>
				<har>HibernateApplication.har</har>
			</module>
		</jboss-app>

While this approach is still advisable if you want to grant backward compatibility to your applications, with release 5.0 of the Application Server you now have a handy quicker solution. As the new VFS of JBoss AS is able to detect the nature of your application by scanning deployment descriptors, it’s enough to pack your Hibernate application in a plain Java ARchive (JAR). JBoss AS will discover the .hbm.xml mapping files and look for the corresponding Java classes. If successful, the package will be deployed as a Hibernate application straightaway.

The corollary of this theorem is that you can leave out, as well, the JBoss AS configuration file jboss-app.xml, which is not necessary any more. The only update required is to your application.xml, where your Hibernate application is declared as a Java module in order to make it available to other enterprise modules.

	<application>
		<module>
			<web>
				<web-uri>HibernateWeb.war</web-uri>
				<context-root>HibernateWeb</context-root>
			</web>
		</module>
		<b><module>
			<java>HibernateProject.jar</java>
		</module></b>
	</application>

This is how your Enterprise ARchive should look like before deploying it:

16:46:18,949 INFO [HbmBinder] Mapping class: com.packtpub.hibernate.

Employee ->employee

16:46:19,261 INFO [HbmBinder] Mapping class: com.packtpub.hibernate.

Department -> department

16:46:19,277 INFO [HbmBinder] Mapping collection: com.packtpub.hibernate.

Department.employees -> employee

In order to test your application, simply recall your JSP default page, using the HibernateWeb context. In our example:

http://localhost:8080/HibernateWeb/

Using the wizard to generate EJB 3

Hibernate tool capabilities are not limited to Hibernate programming. By using the reverse engineering option, you can also generate EJB 3.0 classes in a matter of seconds. Recall the Reverse Engineering Configuration:

Hibernate and EJB: Friends or opponents?

In Chapter 4, we introduced the EJB programming model, so at this stage, you might wonder when it’s more appropriate to use EJB from your projects and when it’s better to stay on the Hibernate framework.

The premise of this debate is that EJB and Hibernate are not fully comparable because they are semantically different. EJBs live in a container, which provides services, such as transactions, concurrent access control, security, instance pooling,and others. On the other hand, Hibernate is classified as an object-relational mapping tool and it is independent from a server container.

So, if comparing EJB and Hibernate is technically a mistake, you can actually compare the Java Persistence API and Hibernate, which are, in some ways, two antagonist technologies. The most important factor, which is in favor of JPA, is that it is a standard. Using industry-standard components allows the business comparatively more fl exibility when it’s necessary to change its business model, to reorchestrate itself, and to collaborate dynamically.

Technically speaking, it is also important to stress that an EJB-centric approach is the appropriate implementation technology for two types of applications:

• Applications that use distributed transactions initiated by remote clients

• Applications that are heavily message-oriented and need message-driven beans

On the other hand, Hibernate framework has reached a vast community of developers and it offers the benefit of peacefully coexisting in various deployment environments, from application servers to standalone applications.

At the end of the day, the choice between the two technologies might be to preserve your well-tested applications backed by Hibernate Persistence and to definitely consider switching to JPA when you are designing a new project from the ground up. What about using them together instead?

Using Hibernate with EJB

A plausible scenario is that some time ago, you designed the persistence layer of your application with Hibernate. Now you need to expose some functionalities of your application through RMI or Web Services.

The good news is that persistent classes that are mapped using Hibernate *.hbm. xml files are supported by JBoss AS EJB 3 implementation. The EJB 3 deployer will search the archive for any .hbm.xml files and add them to the definition of the underlying Hibernate SessionFactory. Let’s see how you can leverage Hibernate objects from the EJB environment.

Injecting key Hibernate objects

If you have been through the Hibernate web application carefully, you might advocate that it is not a pure MVC application, as we are accessing the persistence layer from within the servlet.

This approach can be useful for a learner who wants an easy-to-catch example of Hibernate. However, you can create a clean separation of roles between the controller and the model tier, also by introducing an EJB as intermediary.

From inside your Hibernate project, add another Stateless Session Bean named com.packtpub.hibernate.HibernateDAOBean implementing a local interface com.packtpub.hibernate.HibernateDAOLocal.

Following is a code snippet of the bean implementing the saveEmployee method:

	@Stateless
	@LocalBinding(jndiBinding="HibernateDAO/local")
	public class HibernateDAOBean implements HibernateDAO {
		<b>@PersistenceUnit(unitName="hibernateUnit") [1]
			SessionFactory factory;</b>
		public void saveEmployee(String name,String salary,String
			departmentId) {
			Session hsession=null;
			try {
				hsession = factory.openSession();
				Query query = hsession.createQuery("from Department d where
				d.departmentId = :departmentId");
				query.setInteger("departmentId", new Integer(departmentId));
				Department dep = (Department) query.uniqueResult();
				Employee emp = new Employee();
				emp.setDepartment(dep);
				emp.setEmployeeName(name);
				emp.setEmployeeSalary(Integer.parseInt(salary));
				hsession.save(emp);
			}
			catch (Exception e) {
				// TODO Auto-generated catch block
				e.printStackTrace();
				throw new EJBException(e.getMessage());
			}
			finally {
				if (hsession.isOpen())
				hsession.close();
			}
		}

The most interesting point in this example is that you have injected the Hibernate SessionFactory in your bean by means of the persistence unit named hibernateUnit. Therefore, you have to equip your application with a JPA persistence.xml file:

	<?xml version="1.0" encoding="UTF-8"?>
		<persistence version="1.0" xmlns="http://java.sun.com/xml/ns/
			persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
			xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://
			java.sun.com/xml/ns/persistence/persistence_1_0.xsd">
			<b><persistence-unit name="hibernateUnit" transaction-type="JTA"></b>
				<provider>org.hibernate.ejb.HibernatePersistence</provider>
				<jta-data-source>java:/MySqlDS</jta-data-source>
				<properties>
					<property name="hibernate.dialect"
						value="org.hibernate.dialect.MySQLDialect"/>
				</properties>
			</persistence-unit>
		</persistence>

We leave as exercise to the reader to complete the EJB with all other methods. On the web tier, you will do a clear cut of all the persistence stuff, just taking care to invoke the EJB with the parameters collected from the request. Look how simple and effective your servlet method saveEmployee has become:

	<b>@EJB(mappedName = "HibernateDAO/local")
	HibernateDAO hibernateDAO;</b>
		private String saveEmployee(HttpServletRequest request) {
			Session hsession=null;
			String name=request.getParameter("name");
			String salary=request.getParameter("salary");
			String departmentId=request.getParameter("departmentId");
			try {
				hibernateDAO.saveEmployee(name,salary,departmentId);
			}
			catch (Exception e) {
				e.printStackTrace();
			}
			return employeeList(request);
		}

A snapshot of the complete Hibernate EJB-driven project follows here:

Summary

Hibernate is a fl exible framework that can be used in any Java application environment. In our excursus, we have showed how to develop a sample application that is geared toward a managed environment. In the last two sections of the chapter, we have compared the Hibernate framework with the JPA persistence standard, showing how the two technologies can be coupled in a single application.

In the next chapter, we will learn JBoss AS JMX infrastructure, which was the backbone of earlier releases of JBoss. Even if it’s not the main kernel component anymore, the JMX API is still the glue around many JBoss AS services.