Java Naming and Directory Interface (JNDI) is an interface to connection pools in the Apache Geronimo application server. Through this interface, developers have access to all Java objects, including Enterprise Java Beans (EJBs).
The following article provides concept-rich documentation on how to use JNDI to access connection pools for data sources, Java Messaging Services (JMS), mail sessions, and URL connections: Apache Geronimo JNDI naming and Java resource connection pools, Part 1: Data source connections. URL: http://www-128.ibm.com/developerworks/opensource/library/os-ag-jndi1
However, the mentioned article is written for Geronimo 1.x. This sample tutorial will demonstrate something similar but using EJB 3.0.
The CustomerService application will make use of EJBs to access a database and spit it back to the screen. The point of this sample is to show that you can use JNDI to access an EJB. The overview of the structural content of the EAR file is given in the following example:
persistence.xml references certain Entity Beans and maps them to use certain database pools. In this case, the entity bean Customer is using the database pool CustomerServicePool.
openejb-jar.xml is here because we are using OpenEJB. Nothing special is really defined in this file because we do not have any defined MDBs.
web.xml references the EJB that was created in ProcessCustomerSessionBean.java. By doing this we are allowing the contents inside the WAR to use this EJB.
geronimo-application.xml specifies the module's information and the context-root in which this web application resides. Additionally, it specifies the database pool plan that we want to create while deploying along with the connector that is needed to deploy this plan into Geronimo.
application.xml specifies a connector in which the EAR will use when trying to deploy the embedded database pool (CustomerServicePool.xml).
CustomerServiceJavaBean.java uses JNDI to look up the ProcessCustomerSessionBean EJB.
ProcessCustomerSessionBean.java implements ProcessCustomerSessionLocal by grabbing an EntityManagerFactory by making use of the persistence.xml. It grabs it by using the @PersistenceUnit annotation. Since there is only one persistence unit defined in persistence.xml, we do not need to specify any additional parameters in the annotation.
ProcessCustomerSessionLocal.java defines the business methods that is associated with this bean.
Customer.java is the entity bean that represents the Customer table in the database. By using @Entity, @Table(name = "customer"), and @Id it tells OpenEJB that this is an entity bean, which is representative of the table "customer" and has "customerId" as the primary key. By using these annotations no other configuration is needed inside openejb-jar.xml (no ejb-jar.xml is needed at all).
Customer Service Database
The database that will be used to demonstrate this application is the built-in Derby database. The name of the database will be CustomerDB and it consists of one table:
customerId (PRIMARY KEY)
The CUSTOMER table stores information about one customer.
The tools used for developing and building the Banking applications are:
Apache Derby, an Apache DB subproject, is a relational database implemented in Java. Its footprint is so small you can easily embed it in any Java-based solution. In addition to its embedded framework, Derby supports a more familiar client/server framework with the Derby Network Server.
Apache Maven 2
Maven is a popular open source build tool for enterprise Java projects, designed to take much of the hard work out of the build process. Maven uses a declarative approach, where the project structure and contents are described, rather than the task-based approach used in Ant or in traditional make files, for example. This helps enforce company-wide development standards and reduces the time needed to write and maintain build scripts. The declarative, lifecycle-based approach used by Maven 1 is, for many, a radical departure from more traditional build techniques, and Maven 2 goes even further in this regard. Maven 2 can be download from the following URL:
Configuring, Building and Deploying the Sample Application
Download the CustomerService application from the following link:
After decompressing the given file, the CustomerService directory will be created.
You can checkout the source code of this sample from SVN:
Configuration of the application consists of creating the database and defining the connection pool to access it.
Creating and Populating Database
After starting Apache Geronimo log into the console and follow the given steps to create CustomerDB.
- Select DB Manager link from the Console Navigation in the left.
- Give the database name as CustomerDB and click Create button.
- Select CustomerDB to the Use DB field.
- Open CustomerService.sql in the CustomerService directory from a text editor.
- Paste the content CustomerService.sql to the SQL Commands text area and press Run SQL button.
Use a command prompt to navigate into the CustomerService directory and just give mvn clean install site command to build. It will create the CustomerService-ear-2.0-SNAPSHOT.ear under the CustomerService folder. Now, you are ready to deploy bank application in the Geronimo Application server.
Deploying the Application
Deploying sample application is pretty straight forward as we are going to use the Geronimo Console.
- Scroll down to Deploy New from the Console Navigation panel.
- Load CustomerService-ear-2.0-SNAPSHOT.ear from CustomerService folder in to the Archive input box.
- Press Install button to deploy application in the server.
Customer Service Web Application
To test the sample web application open and browse and type http://localhost:8080/service. It will forward you to the index page of the application which has a direct link to view the Customers.