Archive for category tomcat
Headless Flex Builds on EC2 Using Hudson Against Remote SVN Repo on Assembla with FlexPMD
Posted by admin in assembla, data visualization, ec2, flex, flex builder, flexpmd, hudson, svn, tomcat on November 16th, 2009
We’re doing a current project requiring continuous integration. We also maintain the SVN repo. There’s a lot here and you may/may not need all the pieces. We’re specifically doing headless Flex/DataViz Builds on Amazon EC2 Ubuntu with Hudson against a remote SVN repo on Assembla and have thrown in FlexPMD to see what it can add to our process.
First, some stuff I’ll assume you already have and know how to work with:
- EC2 machine running in the Amazon cloud. We’re using one of the Ubuntu disty’s. I’m going to assume you have all the necessary ports open for things like email and such.
- Hudson. We’re using version 1.326. We’ve used other CI tools but find Hudson to be very user friendly. You’ll need to have a servlet container ie Tomcat and you just pop hudson.war in and you’re ready to rock.
- Remote SVN. You can be using a local one, but. We’re using Assembla since it’s got all the stuff we need to do business in one place and it’s simple to use. Time is money.
- Java installed on your server. We’re using version 1.6.0_07
Stuff you’ll end up downloading/installing/configuring:
- Flex SDK
- Flex Dataviz components
- SVN client
- Ant
- Flex Ant
Step 1, Flex
We’re currently building with the latest stable build of Flex 3.4. Get yourself all logged into your EC2 account and let’s roll. I create a flex/3.4 directory and cd to that directory and then get the latest Flex rev. This is the latest URL:
wget http://download.macromedia.com/pub/flex/sdk/flex_sdk_3.4.zip
Let’s get the dataviz components as well since they’re a separate install
wget http://download.macromedia.com/pub/flex/sdk/datavisualization_sdk_3.4.zip
Oh yeah, and if you’re going to be doing unit testing, might as well get that sucker as well
wget http://download.macromedia.com/pub/flex/sdk/automation_sdk_3.4.zip
Great, so we have all the pieces we need so far. You’ll want to unzip and cp these to wherever you keep your software installs on the server. I’m no unix guru, but, near as I could find out, the common location is /opt.
So, create a /opt/flex directory and unzip the flex_sdk_3.4.zip files there. Then, copy the dataviz zip there and unzip it.
cp datavisualization_sdk3.4.zip /opt/flex
cd /opt/flex
unzip datavisualization_sdk3.4.zip
This will extract the following into the SDK 3 installation
- datavisualization.swc into the frameworkslibs folder
- datavisualization__3.0.9147.swz and datavisualization__3.0.9147.swf into the frameworksrsls folder
- datavisualization_rb.swc into the appropriate frameworkslocale<locale> folder
Let’s make sure we put the Flex compiler on the class path. On our server, the default shell is bash. You’re setup may be different, but essentially, you want to find the properties file for you shell (I’m using /root/.bashrc) and add the following line to the bottom of it:
export PATH=/opt/flex/bin:$PATH
Now let’s test it. You may need to log out and then back into your shell. At the command prompt, enter mxmlc and hit return. You should see something like
Loading configuration file /opt/flex/frameworks/flex-config.xml
Error: a target file must be specified
That’s a good error. It means that the Flex compiler is now accessible on your system. If nothing comes back, you’re just at the command prompt, you may not be using the right shell properties file.
In order to build projects that use the dataviz components without having the watermark on your charts and graphs, you’ll need to apply a Flex license to the installation. You do this in the flex-config.xml file located in /opt/flex/frameworks. Towards the bottom of the file you’ll see some commented out xml for doing so:
<licenses>
<license>
<product>string</product>
<serial-number>number</serial-number>
</license>
</licenses>
Step 2, SVN
We are accessing an SVN repo on our Assembla account. The easiest way to make this happen from the EC2 is to just install SVN. So, from the command prompt:
apt-get install subversion
If you run into any errors, I always find it helpful to refresh the list:
apt-get update
If all went well, you should be able to log into your remote repo:
svn –username <your_username> –password <your_password> –no-auth-cache checkout <some_project_name>
If successful, you’re going to have a checked out version of some_project_name in your current directory.
Step 3, Ant
We’re going to be using Ant as our build process. It will called via a Hudson job. Let’s get and install Ant.
apt-get install ant
Once that completes, you should be able to type ant at a command prompt. If it installed successfully, you should see something similar to (unless there happens to be a build.xml file in your current directory):
Buildfile: build.xml
BUILD FAILED
This is good. We now have Ant installed. The only other Ant specific thing we’ll need to do is copy the FlexTasks.jar from your Flex SDK into your new Ant install.
Let’s find where Ant was installed. At a command prompt:
which ant
(which will most likely return)
/usr/bin/ant
Now, navigate to your Flex SDK Ant lib directory. The Flex SDK now contains the flexTasks.jar we need.
cd /opt/flex/an/lib
Now just copy this to the location of your Ant install’s lib directory (typical):
cp flexTasks.jar /usr/share/ant/lib
If you do not copy this file to the lib directory, you must specify it by using Ant’s -lib
option on the command line when you make a project.
Step 4, Setup Hudson Job
Plugins
I’m assuming you have a working familiarity with Hudson. If not, there’s a ton of info via your install directly and on the web. We have a few extra plugins installed. The Violations plugin is useful for code analysis via PMD files if you structure your ant files to use it. The Email Extension gives you a bit more flexibility than the basic email tool.
Configuration
Here’s a look at few items we needed in the Hudon configuration page to get things to work smoothly
Specify the Ant location on your server.
For the Extended E-mail Notification plugin. We’ve defined an email account on our system called hudson. We also use gmail for our corporate email. We’re essentially relaying to gmail which requires SMTP auth and SSL (note: we haven’t entered anything in the default Hudson E-mail section):
Job Setup
Go the usual steps of creating a new job. Here are the pertinent parts.
In Source Code Management, we’ll need to point to our remote SVN. When you click on the “?” next to the Repository URL, you will see the grey box and be able to provide login credentials to your SVN repo and test the connection:
We’re not going to specify any build triggers. The reason is that Assembla gives the ability to access the post-commit hook in SVN via their “Webhook” plugin. In that tool, all we have to do is specify the Hudson job URL and with each check in of code, the project is checked out, built, and success/failure notification sent to our dev group. This is the key to the ‘continuous integration’ aspect of this whole setup.
We do need to tell Hudson to use Ant to do the builds. We have a target in the build.xml file (that is in the root of our Flex project) called main.hudson. To be on the safe side, I’ve specified the full path to the build file. We specify the ant install we configured in the Hudson configuration page earlier. It would probably be helpful to give it more meaningful name like ‘ant_version_x’.
FlexPMD is another great tool we use that profiles your code based upon a bunch of best practices defined by the Flex group at Adobe. You can also specify your own criteria to use in the analysis. It’s worth checking out. Note the format of the XML filename pattern used. It took a while to figure that part out!
We configure the Editable Email Notification accordingly:
And that’s pretty much it. I’ll be pushing up a blog shortly that will walk through the whole ant build used for this project. It uses modules, all sorts of RSLs, FTP, and so on.
Happy Flexing.
Flex + Cairngorm + Spring ActionScript + Tomcat + WebORB/BlazeDS + Spring Java + Hibernate + MySQL Tutorial Part 4
Introduction
I’ve been playing around with a stack of Flex/ActionScript and Java frameworks and finally came up with one that I’m really pleased with — since I’m reusing these terms throughout the series, please review the acronyms after each, as that’s how I’ll be referring to them in the tutorial:
- Flex
- Cairngorm (”CG”)
- Spring ActionScript (”SAS”), formerly Prana
- Tomcat (”TC”)
- WebORB (”WORB”) / BlazeDS (”BDS”)
- Spring, Server-side Java version
- Hibernate (”HB”)
- MySQL
To that, I’m planing on writing a series of tutorials where each one builds on the previous one. The final tutorial will cover: Flex + Cairngorm + Spring ActionScript + Tomcat + WebORB/BlazeDS + Spring Java + Spring Security + Hibernate + MySQL
- Part 1: Basic Flex + CG Application
- Part 2: Flex + CG + SAS
- Part 3: Flex + CG + SAS + Injecting Services into Business Delegates
- Part 4: Integrated Flex Project + Java Project with Tomcat
Part 4 in our series is really just a setup post that lays the groundwork for hooking in BlazeDS (”BDS”) or WebORB to our existing app which we’ll do in Part 5 — I started to put Flex + Tomcat + BDS/WebORB integration all in one post, but it started getting really long — instead we’ll just focus on creating a Java-based Dynamic Web Project with Eclipse Web Tools Platform (”WTP”) and then modifying our existing Flex project to build and deploy to our new Java project.
Tutorial Goal: Create a new Dynamic Web Project integrated with Tomcat & modify our previous Flex Project to build and deploy to it.
This is extremely basic for seasoned Java developers, but I thought it would be necessary for those that wished to learn how to integrate a Flex project with a Java project inside one Eclipse IDE.
Assets:
NOTE: Usually I provide a working demo, but since it’s not really any different than Part 3 and I didn’t have time to deploy to our Amazon EC2 Tomcat box, I’ll come back to it at a later date.
Prerequisites & Assumptions
- Already have Eclipse WTP (or a similar Eclipse based Java IDE) that allows you to create Dynamic Web Projects that integrate with Tomcat.
- Basic understanding of Java development and deployment into a web container.
What This Tutorial is Not
This tutorial will not provide details on installing Eclipse WTP or other Eclipse based Java IDEs — go here to get a copy of WTP. In addition, it will not focus on Java best-practices, but rather get the developer up to speed quickly on the integration of Flex, WTP, and Tomcat.
NOTE: Most of the code snippets are truncated to be concise and only highlight the lines of code that truly deserve the readers attention, so it’s highly recommended that readers download the accompanying project source files in order to follow along.
Download Tomcat Server
To start things off we’ll simply download Tomcat so we have our application server ready to rock when we start creating our Java project. Go here and download the latest version of the Tomcat server as a zip. At the time of writing this Tomcat 6.0.18 was the latest release.
As a side note, I usually stick all of my servers and app server frameworks on my local hard drive in something like this (just in case you’re trying to stay organized like me):

Location of Tomcat on Local HD
Once it’s finished downloading unzip that sucker and we’ll move on to creating the Java project.
Create a Dynamic Web Project (Java)
Start by changing your perspective to the Java EE Development perspective and then create a new Dynamic Web Project called EmployeeManagementConsoleJava4 in the same workspace as the Flex projects from the earlier tutorials (Part 1, Part 2, Part 3) — you can combine your Flex and Java project into one project (it’s an option when you first create your Flex project), but since we started with a plain old Flex project we’ll keep them separate for the remainder of this tutorial.
The Java4 suffix will just help us indicate that it’s mapped to the EmployeeManagementConsole4 Flex project we’re going to create, as well as the new projects we’ll create in subsequent tutorials.
When you create your new Java project, you’ll be presented with the option to add a server to this project, so here we’ll select the “New” button and browse to our recently downloaded Tomcat server installation — choose Apache Tomcat v6.0 and browse to the tomcat directory we unzipped above:

Dynamic Web Project Tomcat Setup
Click Finish and close out the creation of your Java project — we’ll just keep all the defaults to make things uber simple.
Test Java Project with Tomcat Integration
Start by creating a new index.html file in the WebContent folder in your new Project and toss in “Test” for both the title and the only node value in the <body> tag:

index.html in WebContent
And even though we haven’t written any Java, let’s test deploy our application to the server and start her up.
Down in your Server View of Eclipse (if you don’t see the server view, just goto Window -> Show View -> Servers), right-click on the new server we just created and and select “Add and Remove Projects…” and select your new EmployeeManagementConsoleJava4 and click the Add button — you should see the project show up on the right column, indicating it’s been added to the server:

Add Project to Tomcat
Now start your server by right-clicking on it and selecting Start — you should see the console start to fill up with logging info from the server and hopefully no errors. If you do, try going through the console’s list of errors and fixing them.
At this point I’ll assume you don’t have any errors and you’re ready to test your simple Java project — right-click on index.html and select Run As -> Run on Server and you should see your index page open up in Eclipse’s default browser. The other option is to open up your favorite browser and entering in the following URL:
http://localhost:8080/EmployeeManagementConsoleJava4/index.html.
At this point you should see a white page with the sole word “Test” that we added to our index.html page.
Next we’ll move back to the Flex side and change our Flex Project’s settings to build and deploy to our new Java project.
Create a Server-Based Flex Builder Project
If you don’t already have the project from Part 3 of this series, please download it and import it into Flex Builder (”FB”). Once in FB, copy and paste it into the same workspace as EmployeeManagementConsoleJava4.
NOTE: If you don’t feel like writing all this from scratch, just download my project for Part 4 — listed above.
Modify the Project Property Files
Since we started our Flex project as a non-server based project, we’ll need to make some modifications to our .project, .actionScriptProperties, and .flexProperties files in order to convert the project to a server-based application. These files all exist under the root of the Flex Project’s directory — if you can’t see them, make sure you’re in either the Flex or Flex Debugging Perspective.
As a side note, under the covers we’re modifying the Flex Project’s Properties as if we right-clicked on the project and selected Properties.
.actionScriptProperties
Open up .actionScriptProperties and locate the <compiler> node and add or change the following attributes to look like this:
- outputFolderLocation=”DOCUMENTS/EmployeeManagementConsoleJava4/WebContent/flex”
- rootURL=”http://localhost:8080/EmployeeManagementConsoleJava4/flex”
Your .actionScriptProperties should look like this:
<?xml version="1.0" encoding="UTF-8"?>
<actionScriptProperties
mainApplicationPath="EmployeeManagementConsole4.mxml"
version="3">
<compiler
additionalCompilerArguments="-locale en_US
-use-network=false"
copyDependentFiles="true"
enableModuleDebug="true"
generateAccessible="false"
htmlExpressInstall="true"
htmlGenerate="true"
htmlHistoryManagement="true"
htmlPlayerVersion="9.0.124"
htmlPlayerVersionCheck="true"
outputFolderLocation=
"DOCUMENTS/EmployeeManagementConsoleJava4/WebContent/flex"
outputFolderPath="bin-debug"
rootURL="http://localhost:8080/EmployeeManagementConsoleJava4/flex"
sourceFolderPath="src"
strict="true"
useApolloConfig="false"
verifyDigests="true"
warn="true">
<compilerSourcePath/>
<libraryPath defaultLinkType="1">
<libraryPathEntry kind="4" path=""/>
<libraryPathEntry kind="1" linkType="1" path="libs"/>
</libraryPath>
<sourceAttachmentPath/>
</compiler>
<applications>
<application path="EmployeeManagementConsole4.mxml"/>
</applications>
<modules/>
<buildCSSFiles/>
</actionScriptProperties>
.flexProperties
Open up .flexProperties and locate the <flexProperties> node and add or change the following attributes to look like this:
- flexServerType=”2″
- serverContextRoot=”/EmployeeManagementConsoleJava4″
- serverRoot=”${DOCUMENTS}/EmployeeManagementConsoleJava4/WebContent”
- serverRootURL=”http://localhost:8080/EmployeeManagementConsoleJava4/”
Your .flexProperties should look like this:
<?xml version="1.0" encoding="UTF-8"?>
<flexProperties
flexServerType="2"
serverContextRoot="/EmployeeManagementConsoleJava4"
serverRoot="${DOCUMENTS}/EmployeeManagementConsoleJava4/WebContent"
serverRootURL="http://localhost:8080/EmployeeManagementConsoleJava4/"
toolCompile="true"
useServerFlexSDK="false"
version="1"/>
.project
Open up .project and locate the <projectDescription> node and add the node <linkedResources> after the <natures> node inside <projectDescription> — simply copy and paste the <linkedResources> node from my code snippet below; your .project file should look like this:
NOTE: You need to put the full, absolute path on your machine to your Java Web Project in place of the @@FULL_PATH@@ key I subsituted down below for the path on my machine.
<?xml version="1.0" encoding="UTF-8"?>
<projectDescription>
<name>EmployeeManagementConsole4</name>
<comment></comment>
<projects>
</projects>
<buildSpec>
<buildCommand>
<name>com.adobe.flexbuilder.project.flexbuilder</name>
<arguments>
</arguments>
</buildCommand>
</buildSpec>
<natures>
<nature>com.adobe.flexbuilder.project.flexnature</nature>
<nature>com.adobe.flexbuilder.project.actionscriptnature</nature>
</natures>
<linkedResources>
<link>
<name>bin-debug</name>
<type>2</type>
<location>
@@FULL_PATH@@/EmployeeManagementConsoleJava4/WebContent/flex
</location>
</link>
</linkedResources>
</projectDescription>
Check Flex Project Properties
Just to make sure we did everything correctly, let’s check the project properties by right-click on our Flex Project and selecting Properties -> Flex Build Path. It should look like this:
- Main source folder: src
- Output folder: ${DOCUMENTS}/EmployeeManagementConsoleJava4/WebContent/flex
- Output folder URL: http://localhost:8080/EmployeeManagementConsoleJava4/flex

Build Path Properties
Next let’s check the Flex Server Settings: Project Properties -> Flex Server:
- Root folder: ${DOCUMENTS}/EmployeeManagementConsoleJava4/WebContent
- Root URL: http://localhost:8080/EmployeeManagementConsoleJava4/
- Context root: /EmployeeManagementConsoleJava4

Server Properties
Move Assets Under Source
Something we’re going to change here is the location of the assets directory — we’re going to move it from the root of the Flex project to the Flex src directory — this ensures that our assets are deployed with our Flex app everytime we build the application. If you run a build, you’ll now see that the assets directory is in the bin-debug directory at the same level as the actual Flex application:

Assets Directory New Location
This also means we’ll need to make 2 quick changes in in our Flex app that point to the location of the assets directory:
1. Open up EmployeeManagementConsole4.mxml and locate the line where we’re loading up the Spring Application Context XML config file and modify it’s path such that it’s relative to the Flex application.
private function loadSpringAppContext():void
{
trace("Application loadSpringAppContext");
var applicationContextURL:String;
applicationContextURL = "assets/springactionscript/applicationContext.xml";
// Initializes the applicationContext instance and adds listeners for the context file loading events.
this.applicationContext = new FlexXMLApplicationContext(applicationContextURL);
this.applicationContext.addEventListener(Event.COMPLETE, applicationContextLoadResult);
this.applicationContext.addEventListener(IOErrorEvent.IO_ERROR, applicationContextLoadFault);
this.applicationContext.load();
}
2. Open up applicationContext.xml and locate the line where we set the URL to the XML data and modify it’s path such that it’s relative to the Flex application.
<property name="httpService">
<object class="mx.rpc.http.HTTPService">
<property name="url" value="assets/xml/employee_list.xml" />
<property name="resultFormat" value="e4x" />
<property name="method" value="GET" />
</object>
</property>
Build and Run the Application
Couple last things to get this thing up and running:
- Run a clean on the Flex project: Project -> Clean
- If you expand your Java project, you’ll see a WebContent directory and a new flex directory that was generated for us when we built our Flex project. Copy the assets directory from the root of our Flex project into WebContent
- If your Server is already started, Stop it.
- Right-click on the server and select Clean…
- Restart your sever.
- Right-click on your Flex project and select Debug As -> Flex Application
- The Flex app should show up in the browser.
- Click the “Refresh List” bottom to make sure it still loads the list of employees.
Your Flex app should show up in your browser and look just like Step 3’s finished tutorial, except that it’s running on the Tomcat application server.

Completed Step 4 Flex App
Stay tuned for Part 5 where we integrate Flex and BlazeDS using the RemoteObject.
Installing Tomcat in a Sensible Way in an EC2 Cloud Machine: Part 1
Tomcat on EC2
A couple of us recently attended a great seminar put on by the folks at SpringSource. They discussed some great strategies for large scale deployment of TC in a sensible and extensible fashion into productions environments. The approach works as well in our dev sandboxes as it does in production, so I’ll be following some of the best practices learned from the folks who know it best.
What do I have and what do I need?
Depending on the AMI you chose, Tomcat may or may not be installed. Some distributions come with TC installed already.
I suggest that you don’t rely on the distribution version of TC since it may be one that has been modified by the creators of the distribution. Better to just go to the source and get the latest and greatest.
One great thing about using TC is that you just download the version of your choice, unzip/untar it, and you’re essentially off to the races.
Preparation
Similarly, many disty’s come with Java installed and they again can be specific to the disty. I always like to make sure we have the latest Sun Java installed. Feel free to use the version of your choice but your mileage may vary. I’m going to be using the Sun Java6 JDK
Over to the terminal window and do:
apt-get install sun-java6-jdk
It will take a while for all this and the dependencies to all load. When it’s complete, you can verify the install by doing:
java –version

Download TC
Let’s go to http://tomcat.apache.org There’s plenty of reading there regarding which version does what which we can leave as an exercise. Let’s grab Tomcat 6.x from the left hand side of the page under Downloads. Scroll down the next page and we have some choices:

If you hover over the tar.gz link, you’ll see the path in your browser:
![]()
Cool. So back over to our terminal window on our EC2 machine.
We’ll do a wget command to get this version:
wget http://www.devlib.org/apache/tomcat/tomcat-6/v6.0.18/bin/apache-tomcat-6.0.18.tar.gz
When it’s completed:

Install TC
Now that you’ve downloaded it, let’s move it to someplace more permanent and untar it.
I’m using /usr/local/tomcat but you can use the location of your choice. One of the beauties of TC is that it has no requirements regarding where you install it and almost no requirements about where you store the various folders within as we’ll learn later.
mv apache-tomcat-6.0.14.tar.gz /usr/local/tomcat
tar xvzf apache-tomcat-6.0.14.tar.gz
We’ve now downloaded TC and installed it to a permanent location. Before we go any further, let’s examine what we have and what it all means.
Installing Tomcat in a Sensible Way in an EC2 Cloud Machine: Part 2
Tomcat Directories and How It Launches
Let’s pop into the tomcat directory and see what we have.
We’ll try to understand what’s in each of the directories listed
/bin
This directory is never used during runtime. It’s sole purpose is to store scripts and boostrap libs. This directory contains the startup and stop scripts used to launch and kill TC as well as all the scripts it they call
/conf
This directory contains server level versions of the following files:
- context.xml
- In TC, a context is an application deployed in TC
- tomcat-users.xml
- Provides access control to applications running on the server
- server.xml
- Provides all the connectors, ports, engines, virtual hosts configured in the server
- web.xml
- Following the J2EE spec, this is the config file for the web applications defined at the top server level. It essentially tells the servlet engine what servlets map to which URIs, maps filters, security settings, etc.
- logging.properties
- Allows you define the logging levels within the server although you’ll probably want to set this up on a per application basis. TC now uses the java.util.logging package for logging instead of the previous log4j as the former was found to be a source of memory leaks on hot swaps
- context.xml
- A place to provide <Context> snippets. Usually, each application will contain one of these in the META-INF folder so you can control context settings at the application level
- catalina.policy
- The JVM uses this for security decisions and only if you invoke TC with the –security option
- catalina.properties file
-
- A regular Java properties file sued to set class loader paths, security package lists, and some tunable parameters. One useful feature of it is the ability to set properties that can be referenced in other files.
EG: # Some Setting
some.setting=1234
And in another file such as server.xml
<Connector port=”${some.setting}”
- A regular Java properties file sued to set class loader paths, security package lists, and some tunable parameters. One useful feature of it is the ability to set properties that can be referenced in other files.
-
NOTE: another great feature of TC is that all of these files can exist on a per application basis as well.
/lib
Contains the jars necessary to launch TC. The bootstrap process looks in CATALINA_HOME/lib directory for these jars
/logs
Well, you can only imagine!
/temp
This directory is used by the JVM for temporary files. (java.io.tmpdir)
/work
This is a server level working directory for web applications
/webapps
This is where you place your applications that run within TC.
Understanding the TC Launch Procedure
Typical startup procedure for TC on EC2 machine goes something like this (assuming you’re using bash)
./usr/local/tomcat/bin/startup.sh
By default, this should launch TC on the machine at port 8080. But before you run off and do this, let’s examine the sequence of events that take place when you run this command, the actions that are performed during this launch, and ways to simplify your life in the process.
- startup.sh
The sole purpose of this file is to locate and call catalina.sh with the start option. - catalina.sh
Well, this file does quite a bit. But, the important parts are- Invokes the setclasspath.sh script
- Invokes the setenv.sh script if it exists
- Launches the JVM (if the JVM is located)
- setclasspath.sh
TC is a Java application. In order to run, it needs Java installed on the system. This script if responsible for finding the JVM and making sure it’s on the classpath to run and setting up some variables for use by the JVM. The JVM is found by examining the system classpath for the JAVA_HOME variable. Many tutorials on this subject will tell you make sure you set the JAVA_HOME var in your ~/.bashrc file or even in the startup.sh script. Although these are acceptable, they aren’t the most extensible and flexible approach to use. Which leads us to…… - setenv.sh
The catalina.sh script looks to see if there’s a setenv.sh file in CATALINA_BASE/bin. If it’s there, it’s executed prior to launching the JVM. This is the perfect place to put all of your environment settings specific to a TC instance.
Further along, we’ll examine how to set up TC instances in a way that allows you to control and isolate your deployments. The setenv.sh file is a great place to store things like your JAVA_HOME variable. This allows you to switch between, let’s say, 1.5 and 1.6 and if you find there are issues in the latter, you simple switch back as needed.The setenv.sh file doesn’t exist in the basic install. Simple create one and put all of your environment setting export lines in it. When it’s time to upgrade TC, simply copy it over. Quite slick!
Installing Tomcat in a Sensible Way in an EC2 Cloud Machine: Part 3
Putting it All Together
So, based on the brilliant approach presented by Filip Hanik at SpringSource, let’s build a directory layout and a script or two that will make deployment, management, version control, and resource management intuitive.
An interesting aspect to Filip’s presentation was that he proposed having a TC instance per application. This allows for isolation of your applications in a way that doesn’t allow performance or memory issues of one application to affect other applications. This does present more management overhead and certainly once things are clearly stable, they could be deployed in a combined environment but it was an approach I hadn’t thought of.
The directory structure
- /usr/local/tomcat/apache-tomcat-6.0.18/
This will be the basic TC install for a given version. The run script will be referencing this - /usr/local/tomcat/run.sh
The key to it all. This script will take a start|stop|run input as well as instance number(1 or 2 or etc.) - /usr/local/tomcat/shared/
This folder will contain shared instance data if you do not provide it at the instance level. So if you want to provide a specific server.xml for a given instance, place it in
instance/conf/server.xml, otherwise, the one in shared/ will be used. - /usr/local/tomcat/instance_1/
- /usr/local/tomcat/instance_2/
… - /usr/local/tomcat/instance_n/
These are specific TC instances.
Let’s examine some differences between instances
Instance_1 is running on port 8080 using jdk1.5 and has a connection timeout of 20 seconds and sets the JVM heap to 512m max and 192k per thread.
/usr/local/tomcat/instance_1/bin/setenv.sh
JAVA_HOME=”/usr/local/java/jdk1.5”
CATALINA_HOME=”/usr/local/apache_tomcat-6.0.18”
CATALINA_BASE=”/usr/local/tomcat/instance_1”
CATALINA_OPTS=”-Xmx512m –Xss192k”
/conf/catalina.properties
http.port=8080
/conf/server.xml
<Connector port=”${http.port}”
protocol=”HTTP/1.1”
connectionTimeout=”20000” />
Instance_3 is running on port 8081 and is using jdk1.5 and has a connection timeout of 60 seconds
/usr/local/tomcat/instance_3/bin/setenv.sh
JAVA_HOME=”/usr/local/java/jdk1.6”
CATALINA_HOME=”/usr/local/apache_tomcat-6.0.18”
CATALINA_BASE=”/usr/local/tomcat/instance_3”
/conf/catalina.properties
http.port=8081
/conf/server.xml
<Connector port=”${http.port}”
protocol=”HTTP/1.1”
connectionTImeout=”60000” />
You can hopefully see the beauty and the benefits of an approach like this. You can isolate instances, JVMs, applications, configurations. Or, you can share various pieces and isolate others.
If the Tomcat Seminar by SpringSource is coming to your town, it’s a great presentation for short money.
Installing Tomcat in a Sensible Way in EC2 Cloud Machine: Part 4 Final
Making Sure You Can Access Everything…all the time
So, we’ve come pretty far. We’ve learned what pieces were needed to install TC on our EC2 server. We’ve learned some sensible steps in configuring your deployment environment so that you can run multiple instances of TC in a sensible manner.
All we have left to do is make sure we can access TC via the web and ensure that the server comes back up after a re-boot (if so desired).
Making TC Accessible to the Outside World
Log into your EC2 management console and select the specific instance you have installed TC to. Note the Security Groups that have access to this instance. In order for the world to have access to your instance of TC, you need to enable the port you plan to run it on. In this case, we’ll enable it for the default group.

Navigate to the Security Groups in the console and select the security grouop you want to enable the port for. In this case, we’ll be enabling port 8080 for the default group.
In the Connection Method column, select Custom.
In the Protocol column, select tcp.
In the From Port and To Port columns, enter 8080.
In the Source (IP or Group) column, enter 0.0.0.0/0. This will make it available to the world.
Click the Save button.
![]()
Congratulations, you’re console should now be available at http://<url to your instance>:8080.
Getting TC to Survive a Reboot
Linux installs support a mechanism for restarting services via /etc/init.d. In order to create a startup script so that TC survives a reboot and comes back up, use your favorite editor and create a similar file
vi /etc/init.d/tomcat
Paste in the following:
# Tomcat auto-start
#
# description: Auto-starts tomcat
# processname: tomcat
# pidfile: /var/run/tomcat.pid
case $1 in
start)
# uncomment and supply the correct instance for default start
# we’ll only support start for this script
# sh /usr/local/tomcat/run.sh start <instance number>
;;
stop)
# No need to support this since we’ll use the run.sh stop <instance>
;;
restart)
# Ditto above
;;
esac
exit 0
Make sure the script is executable by:
chmod 755 /etc/init.d/tomcat
And finally, link the script to the startup folders with a symbolic link:
ln –s /etc/init.d/tomcat /etc/rc1.d/K99tomcat
ln –s /etc/init.d/tomcat /etc/rc2.d/S99tomcat







