Related Topics: Apache Web Server Journal, Java Developer Magazine, Open Web Magazine

Apache Web Server: Article

Benefiting From Open Source Development

The goal: cross-platform Java development

Summary
It takes a good amount of planning to develop on Tomcat and successfully deploy to a WebSphere environment. Open source frameworks, such as Spring and Struts, can be used to shield an application from platform-dependent implementation details. Ant is a handy tool that facilitates cross-platform deployments. Special consideration is required to handle application security across different platforms. Coding guidelines designed to avoid platform-dependencies must be followed rigorously.

With all these things in mind, cross-platform Java development is a rewarding goal, because your resulting application will be cleaner, easier to maintain, and can provide a real cost advantage.

Resources and Links

SIDEBAR 1

Configuring Ant for Deployments Between Different Application Servers
We used Ant (Ant 1.6+) to manage configuration, builds, and deployments from local development environments to the integration server, from there to the staging server, and finally to production. The ant scripts needed to handle two main server differences:

  1. The WEB-INF/lib directory had to be populated with any JARs not provided by the application server. Specifically, our Tomcat environment required the optional JDBC 2.0 Package while WebSphere already came with the necessary classes installed.
  2. The security-* elements of the Web deployment descriptor (web.xml) needed to include security-role definitions for deployments to Tomcat. In WebSphere, the security roles were defined at the enterprise application level (application.xml).
The solution was to treat any environment dependencies through parameters and to create configuration files that contained all settings for a server type. We laid the groundwork by explicitly providing a value for the server.type Ant property:

<!-- Server Type property-override customizations (if any) -->
<property name="server.type.config.file"
location="${build.modules.home}/deployment/servertypes/${server.type}.properties"/>
<echo message="server.type.config.file=${server.type.config.file}"/>
<property file="${server.type.config.file}"/>

Having a separate properties-file for each server type was helpful, because it made the deployment process agnostic of the type of server that we deployed to. The main property set in each of these files was deploy.tomcat or deploy.websphere (essentially deploy.server-type). Having these properties allowed us to configure the build-war macro according to the server type to handle the inclusion/exclusion of the JDBC 2.0 optional package (see Listing 1).

Only one of the war-* targets is being called depending upon whether the deploy.websphere property is defined or not. This results in a macro definition of build-war, which has been configured for the target server.

Similarly simply, the appropriate definitions for the security-* elements of the web.xml are handled according to the value of server.type.

<!-- Copy the environment-specific version of the web-security.xml XDoclet merge file -->
<target name="web-security-websphere" if="deploy.websphere">
<copy file="${web.merge.dir}/was-web-security.xml"
tofile="${web.merge.dir}/web-security.xml" overwrite="yes"/>
</target>
<target name="web-security-tomcat" unless="deploy.websphere">
<copy file="${web.merge.dir}/tomcat-web-security.xml"
tofile="${web.merge.dir}/web-security.xml" overwrite="yes"/>
</target>

The targets web-security-tomcat and web-security-websphere are then named as dependencies in other targets that use the XDoclet webdoclet task (which uses the web-security.xml deployment descriptor snippet).

More Stories By Christian Donner

Christian Donner has 20 years of experience in project delivery and consulting. His professional focus includes EAI, BI, CRM, supporting business strategy through the development, implementation, and maintenance of mission critical systems. He is a senior technical architect at Molecular, a Web consulting firm located in the Boston area, and has written for both Java Developer's Journal and .NET Developer's Journal. He can be reached at pubs2005@cdonner.com.

More Stories By Sumitra Chary

Sumitra Chary is a senior software engineer at Molecular. Her career has spanned both academic and commercial worlds. These have included software systems for X-ray observatory missions, network management, marketing automation, and enterprise Web applications.

More Stories By Jim Lamoureaux

Jim Lamoureaux is a senior consultant and software architect at Molecular. His interests include object-oriented design and implementation, programming languages, and software process. Jim is a Sun Certified Programmer for the Java 2 Platform. He currently lives in Southern New Hampshire.

More Stories By Ilia Papas

Ilia Papas is a software engineer at Molecular. He has been working with web applications for five years and has interests in the design and implementation of enterprise applications using a variety of technologies. He currently lives in the Boston area.

More Stories By Dita Vyslouzil

Dita Vyslouzil is a Consultant and Technical Architect in the Engineering group at Molecular in Watertown. She has been in software development for 7 years, concentrating in transactional web applications.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.