当前页面: 开发资料首页 → Netbeans 专题 → Porting a Legacy Web Application to NetBeans

Porting a Legacy Web Application to NetBeans

摘要: Many articles and books dealing with projects in NetBeans start with the assumption that you are developing your project from scratch. This article discusses the steps required if you have acquired an existing web application and want to convert it to use NetBeans as a development and deployment tool

Introduction

Many articles and books dealing with projects in NetBeans start with the assumption that you are developing your project from scratch. This article discusses the steps required if you have acquired an existing web application and want to convert it to use NetBeans as a development and deployment tool.

The steps outlined in this article were the ones I used to port an existing web application to the NetBeans 5.0 IDE. The application is a fairly representative one in that it uses Java server pages, Jakarta struts and JDBC to store the data in a relational database. This is complicated by the fact that it also uses the Spring application framework and Open Symphony object cache to enhance performance.

Reasons to Move

If the web application was already up and running, you might wonder why it was decided to move it to the NetBeans IDE framework. The answer is that NetBeans offers some unique benefits that make using it quite compelling.

First and foremost is that NetBeans offers a unified development environment with an ingrained understanding of both Java and web application requirements. This means that the task of developing and deploying the web application is greatly aided by the use of NetBeans.

Secondly, because there are a large number of people who are already familiar with the NetBeans IDE, finding qualified engineers to make enhancements to the web application becomes an easier task.

Thirdly, NetBeans offers a more integrated model for both automated and one-off unit tests. Unit testing was not a priority when the original web application was developed but is quickly becoming a priority as newer and more complex features are being developed.

Finally, since newer and more complex features were being developed for the web application, the assistance via code completion, syntax checking, and rapid documentation tools made the job of developing new code that much easier and more efficient.

Plan of Attack

In this part of the article, I will take you through the steps I went through to port the legacy web application to a NetBeans 5.0 environment. I will discuss the planning steps you should take before you port, porting the application itself, and proving that the port has been successful.

Audit of Legacy Software

The first step I took was to make sure that I understood the existing application fully. This involved an examination of the source code, the development, testing and running environments, and the build process.

Good documentation in the form of design or development notes is also very helpful at this stage. Access to one or more of the developers of the existing code is also extremely helpful. In my case, I was not so lucky and had to derive my understanding from reading the code base itself.

Building the Existing Web Application

This step is very important. Make sure that you know how to build the current web application using the existing building methodology. This will quickly expose pieces of missing code or other dependencies that you will need to understand as part of moving this code base to NetBeans.

In my case, I built the web application and installed it in my test application server. When I went to run the application, I got a series of JDBC errors that made no sense. A quick telephone call revealed that there was an upgrade to the database export that I had been given that modified the database schema. Once I obtained and applied the upgrade to the database, the web application displayed the results I expected.

Examining the Source Code

Because I did not have access to any design or engineering documents, I needed to start to understand the code by reading it. Since I would be reading the source code, I decided to maximize my time by looking for a number of things in each file. These were:

What did the file do? If it was a class, what was its purpose?
How well did the inline documentation match the code? Was the code commented enough to make the purpose of the code clear?
What dependencies did the code have? These were either in the form of interfaces or libraries.
Was there any associated testing program for this file?

I would strongly recommend that you make notes or sketches of the objects during this phase so that you know approximately what each one does and understand the various relationships between them. The tools you use to capture these notes are up to you. I like to use a UML diagramming tool because I can continue to use that tool to plan my enhancements to the application later on.

Libraries

It is also useful to document any libraries (jar files) that this web application depends upon. This list may be generated by locating all the jar files referenced in the build process, or by finding all the jar files in the code base you have been given, or by referencing all the Java import statements in the code.

In my case, I obtained the list of libraries by finding all the jar files in the code base. Here is the list for my web application:

Library File	Description	Version
classes12	Oracle JDBC Driver	9.0.2.0.0
commons-beanutils	Jakarta Commons Beanutils	1.6
commons-collections	Jakarta Commons Collections	3.1
commons-dbcp	Jakarta Commons Database Connection Pooling	1.1
commons-digester	Jakarta Commons Digester	1.5
commons-fileupload	Jakarta File upload component for Java servlets	1.0
commons-lang	Jakarta Commons Lang	1.0.1
commons-logging	Jakarta Commons Logging	1.0.3
commons-pool	Jakarta Commons Object Pooling Library	1.1
commons.validator	Jakarta Commons Validator	1.0.2
jakarta-oro	Jakarta Oro	1.0
junit	Java Unit Testing Framework	3.8.1
log4j	Logging Framework	1.2.8
mysql-connector-java	MySQL JDBC Driver	3.0.11
oscache	Open Symphony Object Cache	2.1
spring	Spring Application Framework	1.0.2
struts	Java Application Framework	1.1
struts-legacy	Java Application Framework	1.0

A quick check in a browser showed that many of these libraries were no longer up-to-date; however I decided not to upgrade these libraries as part of the porting exercise. Instead, I decided to make updating the libraries one of my first tasks once I had completed moving the code base to NetBeans. There is often a temptation to try to fix too many things at once which makes diagnosing an unforeseen issue very difficult. By forcing myself to only make the changes necessary for the port to NetBeans, I removed additional complexities in the process.

I immediately noticed that the web application has JDBC drivers for both Oracle and MySQL. A quick check of the code showed that previous developers had used MySQL for testing and then Oracle for the production war image.

I set up a to-do list to capture activities I want to do once the code has been moved over to the NetBeans environment; “Update libraries” has been added to that list.

Target Web Application Server

NetBeans comes in various bundle configurations that support different web application servers. These include Jakarta TomCat and Sun Java EE and J2EE application servers with JBoss to be added shortly. You may save a considerable amount of time by downloading one of these pre-configured web server bundles.

Since I knew this application was going to run in a Sun Java EE Web Server environment, I decided to download and install the NetBeans Enterprise Pack bundle that includes a number of features for use in a Java EE environment.

Source Control System

I was surprised to see that the source code I was given had not been placed under any form of source control especially since the web application had been running a production environment for a number of years. I added “place code under source code control” to my post-porting to-do list.

If the web application was already using some form of source control system, I would have had to decide how to handle the port to NetBeans because various files and directories would be re-arranged during the porting process. The main issue would be whether it was necessary to maintain the revision control information from the legacy application in the new NetBeans environment. Maintaining the change history across such a move is very difficult and should be approached with the understanding that it will probably take a lot of time and experimentation to get right.

NetBeans 5.0 provides support for CVS from within the IDE and NetBeans 5.5 will add SVN support as well. A plug-in to support OpenVMS CMS is also available.

Internal Documentation

Since I was examining the source code anyway, I decided it was a good time to determine how well the code had been documented internally. This was especially important because I did not have any design or development notes to go by. Fortunately, the code was reasonably well documented with Javadoc directives, although I did notice some documentation artifacts due to cutting and pasting of code. This usually presented itself as a repeating Javadoc block from the previous code block in the current one. I add “fix internal documentation” to my to-do list.

The code was weak in documenting the internals of the methods themselves. There is a school of thought that says that the code should be written with such clarity that documentation inside the method is not required. While I may agree with this viewpoint as an ideal, I find that code is rarely written this way, so my position is that documentation inside the method is preferred.

Creation of the Web Project in NetBeans

I was now prepared to create a blank web application project in NetBeans. I selected File | New Project from the menu and then Web | Web Application from the New Project dialog screen.

Pressing the Next button caused the New Web Application dialog to appear. I entered my Project Name and Project Location values and then selected my Source Structure.

The Source Structure selector needs a little bit of explanation. There are two major standard layouts for web applications: Jakarta and Java BluePrints. The difference between these two layouts is presented in the following diagram:

Figure 1. Web Application Layout Differences

The highlighted area shows you the difference between the two standards. The Java BluePrint layout is strongly recommended for J2EE environments, so I selected it.

Since I wanted to test my port of the code base without affecting other users, I elected to use the bundled TomCat server that came with my copy of NetBeans 5.0. I set the Context Path appropriately and left the two check boxes checked. I will make sure to do a final test with the Java Web Server product before I release the code to other engineers.

Importing the Application

Now I was faced with the task of moving all the existing source code to the new web application project directories. These are the steps I took:

Java source code including all directories required for the various packages was placed under the src/java directory.
Java property files that were required by the Java source code was also placed in the src/java directory.
The unit test programs were placed in the test directory.
Graphic images were placed in a directory named ‘images’ in the web directory.
Because this application was a Struts-based one, the index.jsp file was also placed in the web directory and consisted of a redirect directive to the struts start page.
The WEB-INF directory contains all the Struts configuration XML files, JDBC property files and cache control property files.
The WEB-INF directory also contained directories named ‘jsp’, ‘lib’ and ‘tld’ to hold Java server pages, Java JAR files and tag library definitions used by the Struts and OSCache Frameworks.

The final layout looked like this:

Modifying the build.xml File

In the process of learning how to build the existing web application using the existing build methods, I was fortunate that the build process was based upon the Jakarta Ant program, however, when I opened the build.xml associated with the Ant build, I found that there were a number of additional ant targets in the file.

Examination of these additional build files showed that the original developer had included the mechanism to perform a database update/rollback as part of the build directive file. Without knowing the factors that went into making the decision to do things this way, my own preference would have been to have a separate file–say, database_upgrade.xml–to handle this task in isolation from the main build file. It could always be invoked as “ant –f database_upgrade.xml” when needed.

The database I was now dealing with had already been upgraded, so I decided to remove these ant targets from the build set.

The build process also made use of an external build properties file–build.properties–to define the details of the database connection and timeout for the session. I adjusted these to reflect my test environment.

Building for the First Time

Once all the source files had been copied to the correct place according to the directory structure shown above, it was time to try to build the web application for the first time. To do this, I selected Build | Build Main Project from the NetBeans menu bar.

The build process went very well, compiling all the Java source code to class files, copying all the files to the build/web directory and then generating the war file for distribution in the “dist” directory.

This also seemed a good time to check that the corresponding Javadoc could be generated for this code. I selected Build | Generate Javadoc for Project from the NetBeans menu. The Javadoc was generated and placed in the “dist” directory. A browser was also started to display the main index page for the documentation set.

Testing the Web Application

Since I planned to test the web application privately first, I selected Run | Run Main Project from the NetBeans menu bar. This caused NetBeans to use the default application server I specified in the Tools | Server Manager management form. The war file created in the building operation was copied to the appropriate location in the web application server file structure and the web server unpacked the file. A web browser window was opened to display the web application running in the web application server.

Since there was already an active instance of the web application running on a production server, I was able to perform side-by-side comparison testing between the local and production copies.

Conclusion

Moving a legacy web application to the NetBeans environment is a relatively easy task if you take the time to plan what you are going to do. The issues that must be addressed as part of the port are:

Can you build the application using the existing (legacy) build methodology?
What web application server will be used for running the final war file? Does NetBeans have a bundle that can assist you in setting up for that environment?
Is the code under some form of source or revision control system? How will you manage the movement of the code to the NetBeans structure?
How will you test that the move to NetBeans has been successful?

NetBeans 5.0 was designed to assist in the implementation of Java-based applications and made the task to porting the legacy web application painless.

As a test, I decided to move the NetBeans 5.0 image described above into a NetBeans 5.5 Beta 2 image. The application ported to the 5.5. environment with no issues and I was able to compile and run it as before.

To-Do List

During this article, I made reference to a number of “to-do” items that I deliberately chose not to address during the port but did want to get to as soon as possible. These were:

Rationalize the libraries and update them to current versions where applicable.
Place the code under a source control system.
Enhance the unit testing to cover the major logical functions of the application.
Update the in-line documentation to synchronize it with the code base.
Rationalize the various properties files to a) understand them more fully and b) determine whether they could be combined into one file.