Our application will be a basic Web application implementing the following use cases:
- Customers need to register on the site to place orders.
- Customers can place orders.
- Customers can view their orders.
- Admin can list all registered customers.
The system will be implemented using a servlet programming model and MySQL database.
Configuring MySQL Database and the Data Source
By default, when MySQL gets installed, a TEST database is available. Be sure to launch C:\Mysql\winmysqladmin.exe to specify the user name and password (the first time you launch it, it lets you do it and also starts the database server). It's necessary to copy MySQL Connector/J JDBC Driver: mysql-connector-java-3.1.10-bin.jar to the glassfish/lib directory, so the glassfish server can recognize it.
To configure MySQL database access in Glassfish, we have to add a separate file called DBTest.xml; the file follows a convention of "application_name.xml" under $GLASSFISH\lib .The only problem with this file is that it may get deleted when the application is undeployed, so if you undeploy and redeploy the application, you have to place this file into the same folder again (so it's a good idea to save it somewhere else).
Building Our Web Application Using Web Tools and a Database
Before we can start working on the Web project, we must configure Glassfish in Eclipse to be our default server. When Web Tools are installed in Eclipse, new perspectives and options are added, such as a J2EE perspective where you can create J2EE projects, Web projects, and Web services. New options are available under the Window-Preferences menu for configuring Glassfish servers with Eclipse. Go to Window - Preferences menu, under Server select - Installed Runtimes, click Add, and then specify Glassfish server with the installed JRE and a path to the Glassfish installation directory. Now create a Dynamic Web Project using the Web Tools wizard by selecting File-New-Other, then expanding Web-Dynamic Web Project.
We'll name the project DBTest, which will also become its context root. The Web module will be targeted to our default server: Glassfish. Click Finish and the DBTest Web project gets created. This project will contain all of our Web resources, such as HTML and JSP files, and servlets.
Creating Supporting Domain Classes and Tables
Before creating servlets, let's create supporting classes to represent a customer and an order. The class diagram in depicts the Customer and Order relationship.
Note that when creating Customer and Order classes, we define corresponding fields as their public instance variables and then can automatically generate getters and setters from those fields. This can be easily done by going to Outline view (appears after you double-click on an existing class name or create a new class), selecting a class, and selecting "Source - Generate Getters and Setters..." from the right-button menu).
Along with the classes, we'd have to create corresponding database tables in a MySQL database:
CREATE TABLE CUSTOMER (
ID INT PRIMARY KEY,
CREATE TABLE ORDERS (
ID INT PRIMARY KEY,
CUST_ID INT REFERENCES CUSTOMER,
Creating Database Command Classes
We'll create a special package with classes that implement a C
ommand design pattern to perform necessary database updates. The Command pattern allows the classes to implement the common interface executing some particular command. Examples of the Command pattern in Java would be classes that implement the ActionListener interface with the actionPerformed() method.
Classes implementing this command will be p
erforming the actual database operations for reading and inserting rows into customer and order tables. The following use cases will be addressed:
- Customers want to register on the site in order to place orders (a new row is created in the customer table)
- Customers can place the order (the order gets created in the database for a particular customer)
- Customers can view the orders they have placed
- Admin can list all the customers
Based on these use cases, the following classes have implemented the DatabaseCommand interface
public class CreateCustomer implements DatabaseCommand
public class CreateOrder implements DatabaseCommand
public class ListCustomers implements DatabaseCo
public class ListCustomerOrders implements DatabaseC
Finally, in order to execute our command classes, we will need to create a class that would access the database datasource, obtain a SQL connection, and then execute a particular database command. This class will implement a Singleton design pattern, which we'll call C
Object o = CommandExecutor.ge
The CommandExecutor class will perf
orm the datasource lookup as follows:
InitialContext ctx = new InitialContext();
Context envCtx = (Context) ctx.lookup("java:comp/env");
ds = (DataSource) envCtx.lookup("jdbc/TestDB");
Creating Servlets and JSPs
The Model-View-Controller (MVC) paradigm requires the implementation of three loosely coupled tiers in the application:
- Model: Business logic and domain objects of the application
- View: Presentation, user interface
- Controller: Something that sits between the model and view, allowing them to interact in a loosely coupled manner, meaning that the model does not have to be aware of the view, and a different view could possibly be used with the same model.
So far we have implemented only Model - domain objects and command classes. Controller will be implemented as a servlet and View will be implemented as JSPs.
Web Tools provides comprehensive wizards and editors for creating servlets and JSPs. We'll start by creating a package called "servlet" in our Eclipse project whe
re all our servlets will reside. Next, we'll launch the wizard for creating a CreateCustomerServlet by selecting File-New-Other, and then Web-Servlet .
On the screen in , we can specify the Web Project and package where servlet should reside,
On this one, we can specify the optional description for the servlet, initialization parameters (that can be retrieved by the servlet in the init() method from its Servl
etConfig object), and URL mapping.
At this point, we are presented with the capability to specify the interfaces that this servlet will implement (by default, all the servlets implement the javax.servlet.Servlet interface), and the methods that should be automatically generated when the servlet is created.
Just click on Finish and the servlet is generated. This also creates the following entry in the web.xml file:
This XML is necessary for the CommandExecutor datasource lookup code to work properly.
In the init() method of ListCustomers-Servlet, we will get the instance of the CommandExecutor, which will retrieve the data source and cache it for future use to supply database connections. It's a good practice to cache a reference to JNDI data source, because retrieving it is a time-consuming operation.
In the doGet() method, we will execute the database command and forward the list of registered customers to the JSP to display them.
In this doGet method, request attribute "customers" is set to the generic ArrayList and then RequestDispatcher object is used to forward a response to customers.jsp Using some of the new features of J2SE 5.0 such as generics and enhanced "for" loop improves the JSP code by reducing the amount of Java code in it. Creating and editing JSP using WTP is simple. Select the Web content folder of your Web project, right-click, and select New - Other from the menu. From the dialog that appears, select Web - JSP, then specify the name of the JSP you want to create. WTP also allows you to select an existing template for your JSP to be based on. Three built-in templates are provided based on HTML, XHTML, and XML.
In a similar way, we can create other servlets and JSP pages in our application (see the source code), which is easy to import into Eclipse by using its File-Import menu, shows the Web site map of our simple Web application. As you can see, users initially get to index.html page from which they can perform all the other tasks, such as creating customers and orders, and listing existing customers and their orders.
Debugging Application in Eclipse with WPT
The debugging application in Glassfish involves launching the server in the debug mode. To do this, simply right-click on the Glassfish server and select "Debug." To debug some particular line of code, insert a breakpoint .
The server currently running in the debug mode will be automatically selected. After a couple of clicks, the embedded browser page should appear. From now on you can debug the Web application the same way as a regular Java program.
Deploying the Application to Glass fish
Once the application has been tested, it may be ready to deploy. To deploy a Web application, first export it as a WAR file. Simply select File - Export - WAR file.
On the popup window you can check "Export source files" and "Overwrite existing file" if you wish to have your source contained within your WAR file (it may not be a good idea in production) and want to suppress a warning if the file with the same name (perhaps a previously exported version) already exists in the directory and you want to simply overwrite it.
Once the WAR file is exported, deploying it to glassfish can be done through the glassfish console, which in our case is located at http://localhost:8080/manager/html.
The console displays currently deployed applications and allows you to deploy new, undeploy, and reload existing applications.
Once deployed, we need to make sure that our DBTest.xml file is still there under $glassfish\lib directiory with all the correct datasource definitions. If it's not, replace it with the correct one that have been saved by you before.
Now, our application is ready to run, so point your browser at http://localhost:8080/DBTest/.