ECLIPSE WEB TOOLS PLATFORM developing java web applications PHẦN 2 doc

Iteration 1: J2EE Web Applications 49
3. Click the Next button to display the Tomcat Server page. Click the Browse
button to select the directory where you installed Tomcat (see the Getting
Tomcat sidebar), for example,
E:\jakarta-tomcat-5.0.28
The Tomcat installation directory field should now show the selected
directory (see Figure 3.4).
Figure 3.4 Tomcat Server
4. The JRE field is initialized to the Workbench default JRE, which is the JVM
you used to launch Eclipse.
JDK Required for JSP Development
Part of the server runtime environment setup process involves specifying the JRE to
use for launching Tomcat. Be sure to specify a full JDK instead of just a JRE because
you’ll be doing JSP development. If you do not currently have a JDK defined to Eclipse,
add the one you previously installed (see the Getting a JDK sidebar). JSP development
requires a Java compiler, which is included in the JDK but not the JRE. JSP compilation
will fail if you specify a JRE. Note that you can precompile your JSPs in order to use a
JRE in your production server environment.
Click the Installed JREs button to open the Installed JREs wizard. This wizard
lets you define additional JREs to Eclipse. Click the Add button and select
the directory where you installed the JDK (see the Getting a JDK sidebar),
for example,
E:\ibm-java2-142
The JDK is added to the Installed JREs page. Select its checkbox to make it
the default JRE (see Figure 3.5), and click the OK button to return to the
Tomcat Server page.
50 CHAPTER 3 • Quick Tour
Figure 3.5 Installed JREs
5. Select the JDK from the drop-down list of the JRE field (see Figure 3.4).
When WTP launches Tomcat later, it will use the specified JDK. Click the
Finish button to complete the definition.

Tomcat is now listed on the Installed Server Runtime Environments page (see
Figure 3.6). You have now extended Eclipse with a J2EE servlet container
and are ready to create your first Java Web application development
project.
Create a Dynamic Web Project
We assume you are familiar with the Eclipse concepts of workspace, project, and
builder. Recall that an Eclipse workspace contains a set of projects. You typically
put projects that are related to each other in the same workspace. For example, in
J2EE development, you would put related Web, EJB, and utility projects in the
same workspace. Each project has a set of builders associated with it. Builders are
what give the project its intelligence. Builders know how to process the artifacts in
a project. The most common example of a builder is the Eclipse incremental Java
compiler, which knows how to compile your Java source files into class files.
WTP provides builders for Java Web applications. These builders know, for
example, how to package the artifacts in J2EE modules so that they can be
deployed to J2EE application servers.
In general, a J2EE application will contain several modules. For example, you
might want to use a Web module for the presentation logic and an EJB module
for the business logic. Here you’ll just develop a Web module. Do the following to
add a Web module to your workspace:
Iteration 1: J2EE Web Applications 51
Figure 3.6 Installed Server Runtime Environments with Tomcat Added
1. To begin development, create a new dynamic Web project by invoking the
File
᭤ New ᭤ Project menu command to open the New Project wizard.
Select Web
᭤ Dynamic Web Project as the project type (see Figure 3.7).
52 CHAPTER 3 • Quick Tour
Figure 3.7 New Project
2. Click the Next button. The Dynamic Web Project page is displayed (see

Figure 3.8). Enter
Web1 in the Project Name field. Note that Apache Tomcat
is selected as the Target Runtime since it is the only server runtime environ-
ment you have defined. The Configurations field lets you select a predefined
configuration of project facets. Leave the setting as <custom> for now. You
can also ignore the checkbox to add the Web module to an EAR project
since Tomcat is just a servlet container and doesn’t support EARs.
3. Click the Next button to advance to the Project Facets page (see Figure 3.9). A
facet is part of the runtime configuration of a project, such as the version of
Java or J2EE. Facets will be discussed in more detail in Chapter 6. For now,
simply accept the selections.
4. Click the Next button to advance to the Web Module page (see Figure 3.10).
You can change some of the project settings here. For example, the Context
Root of the Web application defaults to its project name,
Web1. Accept the
defaults for now.
Iteration 1: J2EE Web Applications 53
Figure 3.8 Dynamic Web Project
Figure 3.9 Project Facets
54 CHAPTER 3 • Quick Tour
5. Click the Finish button to create the Web project. Since this is the first
time you have created a Web project, you are prompted to accept the
J2EE license from Sun (see Figure 3.11). WTP will next attempt to down-
load the J2EE schemas from the Sun Web site, so you must accept the
license before WTP proceeds. Products built on top of WTP may have
obtained the right to redistribute the J2EE schemas, in which case you
won’t see this dialog.
6. Click the I Agree button to accept the license. Note that if you
do not accept the license, then WTP will be unable to validate the
J2EE XML artifacts, such as the deployment descriptors (e.g.,

web.xml),
you create.
WTP has a special J2EE perspective and will attempt to switch to
it when you create any J2EE project, such as a dynamic Web project
or an EJB project. One of the user interface design guidelines of Eclipse is
to not switch perspectives without asking the user if they want to.
You are therefore prompted to switch perspectives (see Figure 3.12).
Figure 3.10 Web Module
7. Click the Ye s button to agree to the switch. The wizard opens the J2EE
perspective for you so you can see the logical structure of your modules.
The J2EE Project Explorer view (see Figure 3.13) now shows the project
structure after
Web1 has been created. Note that the wizard created some
folders and files under the
Web1 module. These items are defined by the
J2EE specification. For example, the
WebContent folder is the root of the
Web application and is where the normal Web content, such as HTML
Iteration 1: J2EE Web Applications 55
Figure 3.12 Open Associated Perspective
Figure 3.11 License Agreement
56 CHAPTER 3 • Quick Tour
Figure 3.13 Project Explorer View
Create and Edit a JSP
Add a JSP file to your project as follows:
1. Add a new JSP file to the
WebContent folder of Web1 as follows. In the
Project Explorer view, expand
Web1, right click on WebContent, and invoke
the New

᭤ JSP command to open the New JavaServer Page wizard. Give the
new file the name
hello-world.jsp. The wizard lets you pick a template
for the new JSP. Select the template for JSP with HTML markup, and click
the Finish button.
2. The wizard creates the JSP file with the content filled in from the template
and opens it in the JSP editor. The JSP editor provides full content assist on
HTML tags, JSP tags, and Java code scriptlets. Edit the JSP to say “Hello,
world” using HTML tags (see Figure 3.14). The Web application is now
ready to run.
pages, JSPs, and images, go. The
WebContent folder contains a special
folder named
WEB-INF, which contains items that are not accessible by a
Web browser. The
WEB-INF folder is where compiled Java code goes. It
also contains a special file,
web.xml, which is the J2EE Web deployment
descriptor; more on that later (see Chapter 7). Now you are ready to
start creating the content of the Web application.
Run the JSP on the Server
The Eclipse Java Development Tools (JDT) lets you run a Java main program
(i.e., a Java class that has a standard
main method) by selecting its source file and
invoking the Run As
᭤ Java Application command. WTP extends the Run As com-
mand to Web artifacts such as HTML and JSP files. Simply select the file and
invoke the Run As
᭤ Run on Server command from the context menu. In WTP, a
server runtime environment plays the role that a Java runtime environment plays

in JDT. Another difference between JDT and WTP is that in JDT, the input and
output of the Java application is displayed in the Console view, but in WTP, the
user interface of a Web application is hosted in a Web browser.
Run your JSP file as follows:
1. Select hello-world
.
jsp and invoke the Run As ᭤ Run on Server command
from the context menu. Since this is the first time you have tried to run any
artifact from the
Web1 project, WTP will prompt you to define a new server
(see Figure 3.15). WTP defaults the server runtime environment to Apache
Tomcat, which you previously associated with the project. However, in
Iteration 1: J2EE Web Applications 57
Figure 3.14 JSP Editor
58 CHAPTER 3 • Quick Tour
WTP a server consists of both a server runtime environment and configura-
tion information such as the port numbers to use and the set of projects to
deploy or publish on it. Note that a project may be deployed on several
servers, which is handy when you are testing a Web application for porta-
bility to different vendors.
Figure 3.15 Define a New Server
2. Click the Next button to advance to the Add and Remove Projects page
(see Figure 3.16).
3. Click the Finish button to confirm that you want WTP to add the
Web1
module to the server configuration. WTP then starts the server and opens
a Web browser with the Uniform Resource Locator (URL) of the JSP file
(see Figure 3.17).
Iteration 1: J2EE Web Applications 59
Figure 3.16 Add and Remove Projects

Figure 3.17 Web Browser—hello-world.jsp
60 CHAPTER 3 • Quick Tour
Summary of Iteration 1
In this iteration you added Tomcat to Eclipse as a server runtime environment, cre-
ated a dynamic Web project, added a JSP file to it, and ran the project on Tomcat.
Congratulations! You have just created your first Web application with
WTP. You’re now ready to add some Java code and do a little debugging.
Iteration 2: Servlets and Scriptlets
The Web application you have created so far is rather boring since it is static.
There is no way to interact with this application. You could have achieved the
same behavior using an HTML page. To liven things up, you will add some Java
code. You’ll add a Java scriptlet to your JSP. This scriptlet will look for a query
parameter in the request and display its value. You’ll also create another JSP to
prompt the user to enter this parameter, and you’ll add a Java servlet to control
the application flow between these JSPs. In this process, you’ll use the debugger
to step through both the JSP and the servlet code. You’ll perform the following
development tasks in this iteration:
1. Add a Java Scriptlet to a JSP.
2. Debug a JSP.
3. Create a Servlet.
4. Debug a Servlet.
Refer to Chapter 7 for more detail.
Add a Java Scriptlet to a JSP
The simplest way to add dynamic behavior to a JSP is to insert a Java scriptlet.
A Java scriptlet is a block of Java code that gets executed when the JSP is
requested. Java scriptlets are placed inside of <% and %> delimiters. Within a
scriptlet, the Java code has access to several predefined variables. For example,
the HTTP request is represented by a
request variable. The scriptlet can re-
trieve the HTTP query parameters from the

request variable.
WTP Launches Tomcat in a New JVM Process
WTP starts Tomcat in a new process using the JVM that you specified when you
defined its server runtime environment. If you have another Tomcat process currently
running, you will be unable to start Tomcat from WTP unless you use a different set
of port numbers (see the Ports Already in Use sidebar earlier in this chapter).
Iteration 2: Servlets and Scriptlets 61
You’ll now make your JSP display the name of the user that is passed in on
the request URL as a query parameter. Query parameters are specified after the
“?” in the URL. For example, to greet Alice, you request the JSP using the URL
http://localhost:8080/Web1/hello-world.jsp?user=Alice
Do the following to add dynamic behavior to your JSP:
1. Edit the
hello-world.jsp file in the JSP editor and add the scriptlets
(see Example 3.1). Here, the Java scriptlet gets the value of the
user query
parameter from the request, checks if it’s null, and creates
a person string
that is then displayed on the page.
Example 3.1 Listing of hello-world.jsp
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<%@ page language="java" contentType="text/html; charset=ISO-8859-1"
pageEncoding="ISO-8859-1"%>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Hello, world</title>
</head>
<body>
<h1>Hello, world.</h1>

<%
String person = "?";
String user = request.getParameter("user");
if (user != null) person = user;
%>
Welcome to WTP, <%= person %>!
</body>
</html>
2. The JSP editor provides full Java code assist within the scriptlet. Experiment
with code assist as you edit the JSP file.
Debug a JSP
You now have some executable code to try out. However, rather than simply run
it, you’ll debug it. Do the following to debug your JSP:
1. Setting a breakpoint in a JSP file is just like setting one in a Java file.
Simply double-click in the left-hand margin on the line where you want
execution to halt. Set a breakpoint now in
hello-world.jsp on the follow-
ing line of the scriptlet:
String user = request.getParameter("user");
62 CHAPTER 3 • Quick Tour
Figure 3.18 Select Tasks
2. Select hello-world.jsp and invoke the Debug As ᭤ Debug on Server
command from the context menu. Since you have modified the JSP,
WTP will prompt you to update the Web application (see Figure 3.18).
3. Check the box to update the context root of
Web1 and click the Finish but-
ton. WTP will update
Web1 and restart the server in debug mode. Since the
server is currently not in debug mode, WTP will prompt you to confirm
the mode change (see Figure 3.19).

Figure 3.19 Debug On Server
4. Select the Switch mode radio button and click the OK button. WTP will
restart the server in debug mode and request the JSP in a Web browser as
Iteration 2: Servlets and Scriptlets 63
before. Execution will now halt at the breakpoint and WTP will attempt
to open the Debug perspective. Since this is a perspective switch, WTP
will prompt you to confirm the switch. Accept the perspective switch
and view the JSP halted at the breakpoint. Use the Debug perspective as
usual to explore the halted state. Click the Resume button to continue
execution.
5. To debug the query parameter handling, go to the Web browser, append
the query string
?user=Alice
to the end of the URL, and refresh the browser. Execution will halt again
at the breakpoint (see Figure 3.20). Click the Step Over button to execute
the line of code that assigns the value
Alice to the user variable. Note that
the Variables view shows the value of the
user variable set correctly.
Figure 3.20 Debug Perspective
64 CHAPTER 3 • Quick Tour
Figure 3.21 Web Browser—hello-world.jsp?user=Alice
6. All of the usual Java debugging functions are available for JSPs. Continue
to explore the variables and step through the code. Click the Resume but-
ton to complete the processing of the HTTP request (see Figure 3.21).
Note that the greeting is now “Welcome to WTP, Alice!”
Create a Servlet
The code for a Web application includes business logic, application logic, and presen-
tation logic. Business logic implements business rules such as how to compute prices
and taxes. Application logic implements the flow of control between Web pages.

Presentation logic implements how the data is rendered in the Web browser. Since
JSPs can contain arbitrary blocks of Java code, it is tempting to put all of the logic in
the JSPs. However, when designing a Web application, it is good practice to limit the
code in JSPs to just the presentation logic. Application logic should be put in servlets
that invoke Java business objects, get the results, and pass them back to JSPs as pres-
entation objects. Business logic should be put in Java classes that are independent of
the presentation and application logic so they can be easily reused and maintained.
Iteration 2: Servlets and Scriptlets 65
You’ll modify your example to illustrate this design pattern. Your example cur-
rently consists of a single JSP,
hello-world.jsp, which checks for the presence of the
user query parameter and displays its value. Users do not normally tack query
parameters on to the end of URLs by hand. Instead, users enter parameters into
HTML forms, and then click a submit button to send the parameters to the server for
processing. To implement this servlet design pattern, you’ll add the following files:
❍
login-user.jsp—a JSP that presents an HTML form to the user and sends
the input to the
HelloServlet servlet for processing. This JSP also displays
an error message if one is present. The error message lets
HelloServlet
communicate with the user.
❍
HelloServlet.java—a servlet that checks for the presence of the user query
parameter. If the query parameter is present and contains a nonempty user
id, the servlet forwards the request on to
hello-world.jsp for presentation
to the user. Otherwise the servlet generates an error message for the user and
forwards the request back to
login-user.jsp.

Do the following to implement the servlet design pattern in your project:
1. Begin by creating
login-user.jsp using the New JSP wizard. Enter its code
(see Example 3.2).
Example 3.2 Listing of login-user.jsp
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<%@ page language="java" contentType="text/html; charset=ISO-8859-1"
pageEncoding="ISO-8859-1"%>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Login User</title>
</head>
<body>
<h1>Login User</h1>
<%
String error_message = "";
Object error = request.getAttribute("error");
if (error != null) error_message = error.toString();
%>
<form action="HelloServlet">
<table cellspacing="4">
<tr>
<td>Enter your user name:</td>
<td><input name="user" type="text" size="20"></td>
<td style="color: red"><%= error_message %></td>
</tr>
<tr>
<td></td>
<td><input type="submit" value="Login"></td>

<td></td>
66 CHAPTER 3 • Quick Tour
</tr>
</table>
</form>
</body>
</html>
login-user.jsp checks for the existence of an optional error message and,
if present, displays it on the page. Note that the
action attribute of the
Login button is set to
HelloServlet. When the user clicks the Login button,
the value of the input field gets sent to
HelloServlet as the value of the
user query parameter. Your next step is to create the HelloServlet.java
class that will process the request.
2. Create the
HelloServlet.java servlet as follows: Select the Web1 project
and invoke the New
᭤ Servlet command from the context menu. This
opens the New Servlet wizard. Create the servlet in the
src directory of the
Web1 project and give it the package name
org.example.ch03
and the class name
HelloServlet
(see Figure 3.22).
Figure 3.22 Create Servlet—Class
Iteration 2: Servlets and Scriptlets 67
Note that the Generate an annotated servlet class checkbox gives you

the option of using XDoclet. Uncheck this option for now. We’ll discuss
XDoclet in Chapter 6.
3. Although you could finish here, click the Next button to view the next
page. The wizard lets you modify the default servlet name and URL map-
ping. Accept the default servlet name
HelloServlet and URL mapping
/
HelloServlet (see Figure 3.23). The servlet name is used for internal
bookkeeping in
web.xml. For example, the servlet name links the servlet
class with the URL mapping. The URL mapping determines how the
servlet is invoked. This value must match the value you specified in the
action attribute of the HTML form element in
login-user.jsp. Although
you use the URL mapping /
HelloServlet, it is a better practice to use a
value that doesn’t expose the implementation details, such as the fact that
you are using a servlet. In practice, you may change the implementation,
so it is a good idea to minimize the number of URLs that are affected.
Figure 3.23 Create Servlet—Deployment Descriptor
4. Click the Finish button. The wizard creates the skeleton of the servlet. All
you need to do is fill in the application logic in the body of the
doGet
method. Enter the code for the servlet (see Example 3.3).
68 CHAPTER 3 • Quick Tour
Example 3.3 Listing of HelloServlet.java
package org.example.ch03;
import java.io.IOException;
import javax.servlet.RequestDispatcher;
import javax.servlet.ServletContext;

import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
/**
* Servlet implementation class for Servlet: HelloServlet
*
*/
public class HelloServlet extends javax.servlet.http.HttpServlet implements
javax.servlet.Servlet {
/**
*
*/
private static final long serialVersionUID = 1L;
/*
* (non-Java-doc)
*
* @see javax.servlet.http.HttpServlet#HttpServlet()
*/
public HelloServlet() {
super();
}
/*
* (non-Java-doc)
*
* @see javax.servlet.http.HttpServlet#doGet(HttpServletRequest request,
* HttpServletResponse response)
*/
protected void doGet(HttpServletRequest request,
HttpServletResponse response) throws ServletException, IOException {
String url = "/hello-world.jsp";

String user = request.getParameter("user");
if (user == null || user.length() == 0) {
url = "/login-user.jsp";
request.setAttribute("error", "User name must not be empty.");
}
ServletContext context = getServletContext();
RequestDispatcher dispatcher = context.getRequestDispatcher(url);
dispatcher.forward(request, response);
}
}
Iteration 2: Servlets and Scriptlets 69
The HelloServlet class implements the doGet method, which handles HTTP
GET requests. The purpose of the servlet is to decide which JSP should han-
dle the request. The servlet computes the URL of the appropriate JSP and for-
wards the request to it using the
forward method of the RequestDispatcher
class. The servlet grabs the user query parameter from the request using the
getParameter method. If the user query parameter is absent, or it is an empty
string, the servlet generates an error message, stores it as an attribute of the
request using the
setAttribute method of the HttpServletRequest class, and
sets the URL to
login-user.jsp. If the user query parameter is present and
non-empty, the servlet sets the URL to
hello-world.jsp.
Debug a Servlet
Debugging a servlet is very similar to debugging an ordinary Java class, except
that you use the Debug As
᭤ Debug on Server command, just as you did for JSPs.
You’ll now debug the application control flow. Debug the servlet as follows:

1. Set a breakpoint in
HelloServlet.java on the line of the doGet method
that contains the code
String user = request.getParameter("user");
2. Select HelloServlet.java in the Project Explorer view and invoke the
Debug As
᭤ Debug on Server command from the context menu. This com-
mand starts the server in debug mode and opens a Web browser with the
URL of the servlet, which in this case is
http://localhost:8080/Web1/HelloServlet
What do I do if I get a 404?
Sometimes when you run or debug a servlet or JSP, you might get a 404 in the Web
browser. This problem is caused by the Web browser requesting the resource before
the server has fully deployed it. WTP detects when resources have changed and
republishes them to the server. However, there may be a time delay as the server
restarts. If you run into a 404, manually restart the server from the Servers view and
try again.
3. Step through the code and verify that there is no value set for the
user
query parameter. The servlet therefore generates an error message and for-
wards the request to the
login-user.jsp. Click the Resume button in the
debugger to allow execution to proceed.
login-user.jsp is displayed in
70 CHAPTER 3 • Quick Tour
the Web browser, with the error message prompting the user to enter a
user id (see Figure 3.24).
4. Do a little testing now. If you click on the Login button, control is passed
back to the servlet, which generates the error message again and forwards
the request back to

login-user.jsp. This time enter a user id and click
Login. Now the servlet forwards control to
hello-world.jsp.
Summary of Iteration 2
In this iteration you created and debugged a servlet that controlled the presenta-
tion logic of your Web application. For simple Web applications, you can code
this logic manually. However, for complex applications, you should consider
using a Web application framework, such as JSF, Struts, or Spring MVC.
In Struts, the control flow logic is externalized into an XML configuration
file so that you can easily modify it. Struts also provides a framework for many
Figure 3.24 Web Browser—login-user.jsp
common Web application programming tasks, such as parameter passing and
error handling. Although Struts enjoys widespread popularity among Java Web
application developers, it is not part of J2EE. The ideas behind Struts have been
standardized in JSR 127: Java ServerFaces, which is now part of Java EE 5. WTP
1.5 includes the JavaServer Faces Tools incubator subproject, which will become
a component of JST in WTP 2.0.
Iteration 3: Database Access
Virtually every Web application takes input from users and stores it on the
server. Relational databases are by far the most popular technology for storing
data. XML promises to become another popular storage format since it is more
convenient for semi-structured data than relational tables. In fact, relational
databases are now being updated to store and query XML data. XML data can
be queried using SQL extensions, XPath, XSLT, and the new XML query lan-
guage, XQuery. We’ll discuss XML more later in Chapters 7 and 10, but for now
we’ll focus on relational databases.
You’ll extend your Web application by adding some very simple database
access. Rather than greet users by their user id, you’ll update your application to
greet users by their full names. You’ll create a relational database to store a table
of full names, and you’ll develop a Java class to access the database using JDBC.

You’ll develop the SQL query using the Data tools in WTP.
The Data tools in WTP use JDBC to access databases. WTP has out-of-
the-box support for many databases and, with a little Eclipse plug-in develop-
ment effort, others can be added. Virtually all databases have JDBC drivers,
so you have lots of choices available, but for purposes of illustration you’ll
use Apache Derby. Derby is very suitable for development with WTP because
it is Open Source, pure Java, and can be embedded easily in Web applications.
If you have another supported database already installed, feel free to use it.
Just modify the following instructions accordingly.
Iteration 3: Database Access 71
Getting Derby
If you’d like to use Derby, download it from
/>The Derby project has packaged the code as an Eclipse plug-in, so download that and
install it in your Eclipse directory. We use version 10.1.2.1 here. You can download
the zip file
72 CHAPTER 3 • Quick Tour
You’ll perform the following development tasks in this iteration:
1. Connect to a Database.
2. Execute SQL Statements.
3. Add Database Access to a Web Application.
Refer to Chapter 9 for more detail.
Connect to a Database
Add a database connection to your project as follows:
Figure 3.25 Derby Plug-In
derby_core_plugin_10.1.2.zip
from
/>To install Derby, exit from Eclipse, unzip the plug-in into your eclipse installation
directory (see Figure 3.25), and then restart Eclipse. Note that when you exit Eclipse,
WTP will automatically stop any of your running servers.
Iteration 3: Database Access 73

Figure 3.26 Show View—Data Views
1. WTP provides two views for working with databases: Database Explorer
and Data Output. The Database Explorer view lets you connect to databases
and examine their contents. The Data Output view lets you see the results
of executing SQL statements on a database. Add these views to the J2EE
perspective as follows:
a. Invoke the Window
᭤ Show View ᭤ Other command from the menu bar
to open the Show View dialog.
b. Expand the Data category (see Figure 3.26), select the Database Explorer
and Data Output views, and click the OK button.
2. WTP adds these views to the J2EE perspective (see Figure 3.27). Feel free to
rearrange these views according to your personal tastes.
3. To work with a database, you need to add a new connection to the Database
Explorer view. In the Database Explorer view, select the Connections folder,
right click, and invoke the New Connection command from the context
menu. This opens the New Connection wizard. Create a new connection to
Derby as follows:
a. Select Derby 10.1 as the database manager.
b. Select Derby Embedded JDBC Driver as the JDBC driver.
c. Enter a convenient directory, for example,
C:\web1db, as the Database
location. This should either be a nonexistent directory or a directory