Packaging and deploying the application
Our 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.
If you have ever worked with JBoss AS and Hibernate, then you might argue that right now something is missing. You're indeed right. Before release 5.0 of the JBoss Application Server, Hibernate classes and mapping files had to be packaged in a JBoss AS custom .har archive. The suffix was determinant, as JBoss AS was able to classify the package as a Hibernate resource.
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> <module> <java>HibernateProject.jar</java> </module> </application>
This is how your Enterprise ARchive should look like before deploying it:
Now deploy your application in the usual way, by adding the project to JBoss AS projects and then choosing Full Publish. The application server will then produce a few log pages; if the binding of classes is successful, you will find the following among your logs:
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:
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:
If you Check the Generate EJB3 annotations checkbox along with Domain code, then the outcome of your reverse engineering process would be simple Java classes with entity annotations. That's a huge saving of time, especially if your database schema is rather complex. You can still adjust your entity beans to your needs once they are generated.
Hibernate and EJB: Friends or opponents?
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 vastly more flexibility 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 EJB3 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.