Tomcat WARs to AWS Elastic Beanstalk or EC2?

[Tommy Griffith]

Hello. I've been looking at videos, etc. and I am still pretty confused about this.

Basically, I currently have this...it's straight-forward...

Tomcat 9, JRE 9

two wars in tomcat9/webapps

several external jars such as ojdbc6.jar, tools.jar, ncso.jar...etc stored in tomcat9/lib

one resource war config file (app_name.xml) stored in tomcat9/conf/Catalina/localhost/app_name.xml


How does all this junk get redeployed in Elastic Beanstalk? Is it a mess? Can it be done via one bundle or does it require source code mods?

I know the resource app_name.xml has parameters like docBase="C:/tomcat9/webapps/app_name"..path="/app_name"...workDir="work\Catalina\localhost\app_name"... in addition to the JDBC resource mapping to Oracle.

thank you so much.

[Tim Holloway]

Ummmm. It's been a long time and EB has probably changed a bit, but here's how it should be working.

An EB instance of Tomcat is an isolated Tomcat (probably running in a container). It is essentially its own little VM with a JVM, all ready to run and to wire into your virtual network.

It's also running under Linux, so forget all that C:\ stuff, but that's another matter.

If memory serves, you should be able to define and configure it from the AWS web GUI, a config file (XML and maybe JSON), or an API (Python).

There are 3 things you generally have to do to deploy a complex webapp in Tomcat:

1. Add any libraries (JDBC drivers and other webapp-sharable resources) into TOMCAT_HOME/lib
2. Define the webapp itself, either by dropping a WAR directly into TOMCAT_HOME/webapps or installing the WAR and configuring it via a Context xml file in TOMCAT_HOME/conf/catalina/localhost
3. Optionally, but hopefully not by modifying Tomcat's config files, especially TOMCAT_HOME/conf/server.xml

The EB API should have elements that handle all 3 of these tasks.

One thing to note, however, is that the path attribute in a Context in conf/Catalina/localhost is not the context path that Tomcat will use - instead the filename of the Context file (excluding the ".xml" extension) will be what the app deploys under. That's a general Tomcat thing, not AWS-specific. Also, usually you can let the app's workDir default to TOMCAT_HOME/work.

[Tommy Griffith]

Thank you. I am still a little confused on where the resource config file would go. It would be referenced by name, it appears, and I see where the GUI could handle everything else. Not sure how to get this file in there.  Would the dpcBase="C:/tomcat9/etc..etc.. have to change?

[Tim Holloway]

What do you mean by "resource config file"? If it's properties used by the webapp, it would be something that you'd build into the WAR, regardless of whether you were running it locally or via AWS/EB.

If you mean the webapp config file, formally known as the "device-dependent deployment descriptory" or in Tomcat as the context XML file, you have 2 options: 1) create a /META-INF/context.xml file in the WAR or 2) define it via the deployment system - which is what you'd be doing if you'd defined a Context XML file under TOMCAT_HOME/conf/Catalina/localhost. It's likely that the individual elements of the Context will be separate items in the EC deployment data rather than an independent Context file to be copied, since Elastic Beanstalk is running the copy of Tomcat and therefore doing the management of the Tomcat server.

[Thomas Griffith]

Tim Holloway wrote:What do you mean by "resource config file"? If it's properties used by the webapp, it would be something that you'd build into the WAR, regardless of whether you were running it locally or via AWS/EB.

Thanks so much. Oh, I meant the context xml in conf/Catalina/localhost...it has the name <webapp>.xml. It specifies a JNDI data source mapping.

So, EB pretty much has a GUI interface to upload WAR, external JARS from TOMCAT_HOME/lib and the context.xml from conf/Catalina/localhost?

If this is the case, is it anticipated that developers continue to mess around (dev and trial and error testing) in localhoust Tomcat instnaces? Then deploy to EB?

Thanks so much for reading my stuff.

[Tim Holloway]

Well, EB has several interfaces. In addition to web control, for example, you can work with EBS (and other parts of AWS) using command-line scripts.

Amazon is often inexpensive, but not always free and most desktop systems today have more than enough power to run Tomcat, so as a general rule, expect that a lot of the development and testing work will be done in in-house machines. Aside from being "free", you also have more direct control over what they are doing so it's easier to poke around and find bugs, fine-tune and fix things.