Web App Solution Blog » tomcat

Headless Flex Builds on EC2 Using Hudson Against Remote SVN Repo on Assembla with FlexPMD

admin — Mon, 16 Nov 2009 14:37:40 +0000

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
Email

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 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:

string
number

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 –password –no-auth-cache checkout

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.

Tweet This Post

Flex + Cairngorm + Spring ActionScript + Tomcat + WebORB/BlazeDS + Spring Java + Hibernate + MySQL Tutorial Part 4

brianr — Thu, 11 Jun 2009 14:51:25 +0000

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 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 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 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:

.flexProperties

Open up .flexProperties and locate the 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:

.project

Open up .project and locate the node and add the node after the node inside — simply copy and paste the 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.



	EmployeeManagementConsole4
	
	
	
	
		
			com.adobe.flexbuilder.project.flexbuilder
			
			
		
	
	
		com.adobe.flexbuilder.project.flexnature
		com.adobe.flexbuilder.project.actionscriptnature
	
	
		
			bin-debug
			2
			
		@@FULL_PATH@@/EmployeeManagementConsoleJava4/WebContent/flex

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.

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.

Tweet This Post

Installing Tomcat in a Sensible Way in an EC2 Cloud Machine: Part 1

admin — Thu, 07 May 2009 15:17:29 +0000

Part 1 2 3 4

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.

Tweet This Post

Installing Tomcat in a Sensible Way in an EC2 Cloud Machine: Part 2

admin — Thu, 07 May 2009 15:07:12 +0000

Part 1 2 3 4

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 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

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!

Tweet This Post

Installing Tomcat in a Sensible Way in an EC2 Cloud Machine: Part 3

admin — Thu, 07 May 2009 14:55:05 +0000

Part 1 2 3 4

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
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
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.

Tweet This Post

Installing Tomcat in a Sensible Way in EC2 Cloud Machine: Part 4 Final

admin — Thu, 07 May 2009 14:06:39 +0000

Part 1 2 3 4

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://: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
;;
stop)
# No need to support this since we’ll use the run.sh stop
;;
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

Tweet This Post