Coffea Works

J2EE Development with Zero Impact on Process

An Innovative Approach to J2EE Programming

by Brian Deeley

Rather than discussing frameworks, philosophies or patterns, this article focuses on the development environment itself, streamlining the tools you already have, and introducing some tools to help the performance of your Java application. The tools considered are Eclipse, Apache Ant, Apache Tomcat, and the Enerjy Software profiling tools.

Introduction
The world of J2EE is, by definition, a collaboration of servers and clients; therefore, it is not surprising that fitting all of its pieces into an Integrated Development Environment (IDE) is a difficult task. Many IDEs are good at compiling and debugging Java code, but most fail to meet the needs of the J2EE developer. Besides Java classes, there are JSPs, EJBs, static content, and endless XML configuration files. Despite the requirements that all application servers adhere to a common specification, each vendor's application server has its own quirks and configuration issues. Standard Eclipse offers you little or no help at all, not even coloring a JSP for you. Eclipse plugins are available and some are even free. MyEclipse is a solid plugin, which is virtually given away, and the Lomboz plugin is free but has less features. The Eclipse Web Standard Tools (WST) project sounds promising but is in early stages of development. On the expensive side of things is WebSphere Studio Application Developer (WSAD), which is great if your company wants to pay for it, but 'heavy' in terms of size due to the extensive feature set (the download is over 2Gb). There are other commercial offerings from Borland, BEA and Oracle, but each has a price and a list of proprietary features which all have substantial learning curves.

How do you construct a good J2EE Development Environment? Depending on how you collaborate with your team, the goal of most programmers should be to construct a microcosm that is as close as possible to your production environment. I use the term "microcosm" because it should be free of outside influence, and you should be able to start, stop and destroy it at will, without affecting any other systems. All source code should be integrated into a version control system, hopefully one that has very little user overhead, but excellent history tracking and reversion features. Releasing or moving a project from development to Q/A should be a simple, automated process with minimal configuration between environments. Ideally, 'war' or 'ear' files should be used while transitioning between machines. Finally, a developer should have a simple, effective means of profiling the performance and memory consumption of the project with results tied directly to source code.

The Environment
What follows is one possible solution for an environment that incorporates all the aforementioned features and will enable you to develop J2EE applications with zero impact on process. Eclipse is emerging as the clear front-runner in the Java IDE market. It is stable, free, and has a great deal of market support. It offers excellent version control system support and has all the debugging, code navigation, and code insight functionality that today's developers expect. The Enerjy Software Profilers plug smoothly into Eclipse and offer developers memory, performance and thread profiling, all within the friendly confines of the Eclipse IDE. Out of the box, Eclipse does not offer integration with application servers, but this is easily accomplished with the help of a simple Ant build.xml script. Apache Tomcat is used for this example because it is widely received, and fits well into our demonstration. Several other application servers work equally well, but require slightly different Ant configurations.

Tomcat
The merits of Tomcat could be discussed ad infinitum, but for the sake of this article, we will demonstrate the ease of deployment, the dynamic reloading of servlets, and its straightforward configuration. To set up our environment for ease of use, we will have to make a small change to the server's main configuration file. Be careful what you do to this file because you can quickly make your instance of Tomcat an unstable or dead kitty. Tomcat has a straightforward set of hierarchal elements, as listed in Table 1.

Table 1: Tomcat's Set of Hierarchical Elements
Intermixed within these elements you will see Listeners, Connectors, Realms, and Loggers. It would be essential to configure them if this server was in production, but for development purposes, you will be well suited with the default values:

Go to the directory where Tomcat has been installed, usually referred to as "CATALINA_HOME".
Open the server.xml file found in CATALINA_HOME/conf, either in Eclipse or in your favorite text editor. Look for the default host. It is probably the only one you have defined, and will look like this:

Fig. 1: Definition of the default Host element

Ignore all the other things in this element and insert the following line just before the closing '':

Fig. 2: Definition of the project Context element

Figure 2 is important to our environment's setup and needs some explanation:

The "path" attribute describes what URLs your localhost will respond to. I leave it blank because I can only develop one web application at a time, and I like the convenience of typing localhost:8080 to get to my web application when I am working.
The "reloadable" attribute is set to "true" and tells Tomcat to pay attention every time you make a change to a servlet or class. This feature will have a negative effect on performance, but (as explained later in this article) it is extremely useful during development. Ensure this is set to "False" on your production server.
The "docBase" attribute should be set to the root directory of the application you are working on. This way there is no need to move files around when you are developing. The "web" directory holds any JSP's, HTML files, and images used in your application. It also needs to include the WEB-INF directory, which houses your compiled classes and any external JAR files you might need.
The aptly named "workDir" is the directory where Tomcat will put all its temporary files. This includes all ".java" and ".class" files created from JSPs. If you leave this blank, Tomcat will write these to CATALINA_HOME/work.

Ant
An Ant plugin comes installed by default with Eclipse, but it is a good idea to download the latest build from the official Apache web site. Besides being a flexible build tool, Ant is also the de facto standard in Java project development. Having a build.xml script associated with your project will greatly help with portability. If you have a build.xml script in your project's root directory, 'right click' in the Eclipse Package Explorer pane and select "Import..." and then "Existing Ant build" file. After this is done, go up to Window Show ViewAnt. In the Ant view, every target defined in your build.xml file will show up with a target. Double click on a target and it will be executed.

For this project, I have nine Ant tasks set up:

Fig. 3: The Ant view in Eclipse

Table 2: The Ant Tasks Set Up for our Project
After you download and unzip Tomcat there are a couple of ways you can control the server. In a Windows world, you could install Tomcat as an NT service, but it has been seen that this gives you less control over the server, and it may be difficult to find the 'services' menu from the Windows Start button. A more holistic approach is to go to CATALINA_HOME/bin from the command prompt and run the startup.bat script. This will open up a new Command Line window displaying all the startup information, and any errors Tomcat throws while it starts up. To save time involved in running this from the command line, I wrote an Ant task to do the work, so I do not have to leave Eclipse (see Figure 4):

Fig. 4: The Start Target defined in an Ant build.xml Script

Double click on the "start" button in Eclipse and Tomcat should come up; "stop" and "restart" work the same way. The profile tasks also start Tomcat but pass an argument to the JVM before Tomcat starts so the Enerjy Software Profilers can be enabled.

Eclipse
Once you have Tomcat configured and imported the Ant build script, you will see how smooth web application development can be. Open your project, start Tomcat, and open a servlet in the editor pane in Eclipse. With your environment set up in this fashion, you can edit your servlets dynamically and not worry about deploying your application or restarting the server. Click on the "build" button in your IDE and your servlet will be compiled and recognized by the servlet container. This ease of use/lack of deployment cannot be overstated; it will save you hours. If you have made changes to the web.xml file, it is necessary to stop and restart the web application - this task is also facilitated by the Ant "restart" task.

One of the great mysteries to new J2EE developers is the lifecycle of JSPs. When a server receives the first request for a JSP, the container translates that JSP into a Java servlet that handles the current and future requests to the JSP. Since we have already instructed Tomcat on the location of temporary files, we will have a keen insight into this process as it happens. When a JSP crashes or falls victim to a "request time error" Tomcat will display an error page including a stack dump with line numbers where the error occurred. By setting this attribute to a convenient directory inside the project you are working on, you will have fast access to the actual source code of the servlet created from the JSP. For those of us who are guilty of ignoring proper MVC patterns and actually have Java code in our JSPs, accessing these files by looking in the work directory from within your IDE makes development that much faster.

Fig. 5: Java Source Code translated from a JSP Page

Enerjy Software
Whether you are developing a banking application, an e-commerce site, or a pet store example, user experience is your ultimate design criteria. As the general population becomes more computer literate, end users are becoming more demanding, and are expecting higher levels of performance from your applications. Poor performance is no longer accepted and the length of time a user will wait before giving up on your application is shorter than ever. Poor performance to the user may be obvious, but to the developer it is both a conundrum and maybe symptomatic of a poor design. Careless memory usage, performance bottlenecks and thread deadlocks are commonplace in Java applications and result in huge costs in downtime and code redesign. So why do so few developers incorporate memory and performance analysis at any stage during development? Developers will usually state that time is the leading reason that their application was not profiled before production. Difficult release schedules are prevalent everywhere in the market place, but it is a lack of foresight to not set guidelines and benchmarks for application performance.

The Enerjy Software Profilers were created with the developer's needs in mind, under the outlandish assumption that profiling tools should be simple to use. Rather than confuse you with intricate call graphs and complex configurations the Enerjy tools keep you inside your IDE and closer to your source code. In Eclipse, any class that can be invoked from the run menu can be easily profiled with a simple dropdown menu. With a J2EE application there is one extra step involved, a single JVM argument needs to be passed to the server when it starts. Enerjy calls this "Remote Profiling" because its actually opens up a socket between the process which is running your application server and the process running Eclipse. What is unique about the Enerjy Profilers is not just the clever integration with the IDE, but in the J2EE world, it is all about on-the-fly, dynamic profiling. Anyone who is familiar with using a profiler will tell you that it can collect a huge amount of data and cause the machine that is collecting the data to slow down. The Enerjy Profilers combat this by allowing you to only collect the data you want, when you want it. On-the-fly profiling allows you to configure the profiler while it is running; there is no need to start and stop the application or application server just to change the configuration or focus on a different method.

Fig. 6: The Enerjy Memory Profiler Settings are configured from the Preferences Menu in Eclipse

To set up the Enerjy Profilers to work in our environment, tell the tool that you want to use remote profiling and which port you want to communicate on. In Eclipse, go to Windows Preferences Enerjy, and select Memory Profiler. Click on the "Remote Settings" tab and select the "Enable remote profiling on port:" box. Enter a port number and ensure that they match the value in your Ant script. Repeat this process for the Performance and Thread Profiler. You are now ready to profile your J2EE application.

The previously mentioned Ant script has three Enerjy profiling targets that correlate with the three profilers (Enerjy Memory Profiler, Enerjy Performance Profiler, and Enerjy Thread Profiler). To begin profiling, double click on the 'profilemem' Ant target. Tomcat will try to start, but will pause while it waits for your profiling instructions. Go back to Eclipse if the Tomcat window is in your way, and you should see the Enerjy Memory Profiler configuration screen.

Fig. 7: Enerjy Memory Profiler is started with Zero Overhead

This is the only configuration screen you will see with Enerjy Memory Profiler. After all, it is neither interesting, nor necessary, to know the memory usage of your application server while it is coming on line, and doing all of its class loading. Deselect all check boxes and hit OK. Tomcat will now start normally with Enerjy Memory Profiler activated, and zero overhead affecting your application. You will now see the Enerjy Memory Profiler status, or "dashboard" view.

Fig. 8: The Enerjy Memory Profiler Status View

The tool provides you with a simple heap graph, and a list of all threads running with a state indicator. You are also given control buttons to take a snapshot, change the tools configuration, and pause and start the application. Wait until the heap graph stabilizes or flat-lines, and hit the "wrench" button. You will see the same configuration dialog that came up when Tomcat started, but now we will put the Profiler to work to examine the memory usage of our application. First turn on the "Collect heap usage data" feature, and leave the default value of 250 milliseconds. Next, select the "Collect detailed allocation metrics for methods" box, and click on the "Add" button to select a method.

Fig. 9: Enerjy Memory Profiler Allows you to Choose which Method to Focus On

Every method on your path is available here. Traverse the tree to your projects' package, and select a doGet() or a doPost() method. Open a web browser and go to a page that will call the method you chose. After it finishes loading, go back to Eclipse and hit the snapshot button. You will now have Object Graphs, Metrics, and Leaks.

Fig. 10: Enerjy Memory Profiler provides Snapshots of the Memory Consumption of the Application

After starting Tomcat and looking at your doGet() method or your Controller servlet, are you concerned that the problem might be with one of your JSPs? Hit the "wrench" button again and change the method you picked to profile. Scroll up to the top of the dialog box and expand the '' tree. Due to the way Tomcat's work directory was set up inside the project, every JSP file that Tomcat has compiled will be available to profile.
Hint: To get everything that your JSP is doing, try selecting the _jspService() method and hit the JSP page again.

Fig. 11: Enerjy Memory Profiler is Focused on a JSP Method

Conclusion
This J2EE development process solution works well because of the great flexibility of the Apache Ant build tool and the powerful simplicity of the Enerjy Software Profilers. Only Enerjy Memory Profiler has been demonstrated here, but we invite you to look at Enerjy Performance Profiler and Enerjy Thread Profiler, as they will make a significant impact on the speed and performance of your applications.

Because J2EE applications are not stand alone processes, but rather multi-layered, multi-tiered beasts, it can be daunting to track down performance issues and causes of application failures. Why is your application so slow? Is it your MVC implementation? The Servlet Container? Your database connections? The Enerjy Software Profilers enable you to peel back layers of complexity, and point you directly to the problem in your code.

About the Author
Brian Deeley: Brian Deeley is a Java Sales Engineer for Enerjy Software. He previously worked for GE Medical Systems in the diagnostic imaging group before joining Matrix Consultants as a Java Architect. Brian holds a bachelors degree in Engineering from the University of Massachusetts, USA.

References