Deploying Java Apps

The following topics describe how to deploy apps to a Java App Server layer's instances.
The examples are for JSP apps, but you can use essentially the same procedure for
installing other types of Java app.

You can deploy JSP pages from any of the supported repositories. If you want to
deploy WAR files, note that AWS OpsWorks Stacks automatically extracts WAR files that
are deployed
from an Amazon S3 or HTTP archive, but not from a Git or Subversion repository. If
you
want to use Git or Subversion for WAR files, you can do one of the following:

Store the extracted archive in the repository.

Store the WAR file in the repository and use a Chef deployment hook to
extract the archive, as described in the following example.

You can use Chef deployment hooks to run user-supplied Ruby applications on an
instance at any of four deployment stages. The application name determines the
stage. The following is an example of a Ruby application named
before_migrate.rb, which extracts a WAR file that has been
deployed from a Git or Subversion repository. The name associates the application
with the Checkout deployment hook so it runs at the beginning of the deployment
operation, after the code is checked but before migration. For more information on
how to use this example, see Using Chef Deployment Hooks.

When you deploy an update to a JSP app, Tomcat might not recognize the update
and instead continue to run the existing app version. This can happen, for
example, if you deploy your app as a .zip file that contains only a JSP page. To
ensure that Tomcat runs the most recently deployed version, the project's root
directory should include a WEB-INF directory that contains a
web.xml file. A web.xml file can
contain a variety of content, but the following is sufficient to ensure that
Tomcat recognizes updates and runs the currently deployed app version. You don't
have to change the version for each update. Tomcat will recognize the update
even if the version hasn't changed.

Deploying a JSP App

To deploy a JSP app, specify the name and repository information. You can also
optionally specify domains and SSL settings. For more information on how to
create an app, see Adding Apps. The following procedure shows how to
create and deploy a simple JSP page from a public Amazon S3 archive. For information
on how to use other repository types, including private Amazon S3 archives, see Application Source.

The following example shows the JSP page, which simply displays some system
information.

The following procedure assumes that you are already familiar with the
basics of creating stacks, adding instances to layers, and so on. If you are
new to AWS OpsWorks Stacks, you should first see Getting Started with Chef 11 Linux Stacks.

Copy the code to a file named simplejsp.jsp, put
the file in a folder named simplejsp, and create a
.zip archive of the folder. The names are
arbitrary; you can use any file or folder names that you want. You can
also use other types of archive, including gzip, bzip2, tarball, or Java
WAR file. Note that AWS OpsWorks Stacks does not support uncompressed tarballs. To
deploy multiple JSP pages, include them in the same archive.

You can now go to the app's URL and view the app. If you have not specified a
domain, you can construct a URL by using either the instance's public IP address
or its public DNS name. To get an instance's public IP address or public DNS
name, go the AWS OpsWorks Stacks console and click the instance's name on the
Instances page to open its details page.

The rest of URL depends on the app's short name, which is a lowercase name
that AWS OpsWorks Stacks generates from the app name that you specified when you created
the
app. For example the short name of SimpleJSP is simplejsp. You can get an app's
short name from its details page.

If the short name is root, you can use either
http://public_DNS/appname.jsp
or
http://public_IP/appname.jsp.

Otherwise, you can use either
http://public_DNS/app_shortname/appname.jsp
or
http://public_IP/app_shortname/appname.jsp.

If you have specified a domain for the app, the URL is
http://domain/appname.jsp.

The URL for the example would be something like
http://192.0.2.0/simplejsp/simplejsp.jsp.

If you want to deploy multiple apps to the same instance, you should not use
root as a short name. This can cause URL conflicts that prevent
the app from working properly. Instead, assign a different domain name to each
app.

Deploying a JSP App with a Back-End
Database

JSP pages can use a JDBC DataSource object to connect to a back
end database. You create and deploy such an app by using the procedure in the
previous section, with one additional step to set up the connection.

AWS OpsWorks Stacks creates and initializes the DataSource object, binds it to
a logical name, and registers the name with a Java Naming and Directory
Interface (JNDI) naming service. The complete logical name is
java:comp/env/user-assigned-name.
You must specify the user-assigned part of the name by adding custom JSON
attributes to the stack configuration and deployment attributes to define the
['opsworks_java']['datasources'] attribute, as described in the
following.

Assign the AWS-OpsWorks-DB-Master-Server
(security_group_id)
and AWS-OpsWorks-Java-App-Server
(security_group_id)
security groups to the instance. AWS OpsWorks Stacks creates these security
groups for you when you create your first stack in the
region.

Create a database named simplejspdb.

Ensure that the master user name and password do not contain
& or other characters that could cause a
Tomcat error.

In particular during startup Tomcat must parse the web app
context file, which is an XML file that includes the master
password and user name. If the either string includes a
& character, the XML parser treats it as a
malformed XML entity and throws a parsing exception, which
prevents Tomcat from starting. For more information about the
web app context file, see tomcat::context.

Copy the example code to a file named
simplejspdb.jsp, put the file in a folder named
simplejspdb, and create a
.zip archive of the folder. The names are
arbitrary; you can use any file or folder names that you want. You can
also use other types of archive, including gzip, bzip2, or tarball. To
deploy multiple JSP pages, include them in the same archive. For
information on how to deploy apps from other repository types, see Application Source.

You can now use the app's URL to view the app. For a description of how to
construct the URL, see Deploying a JSP App.

The URL for the example would be something like
http://192.0.2.0/simplejspdb/simplejspdb.jsp.

Note

The datasources attribute can contain multiple attributes.
Each attribute is named with an apps short name and set to the appropriate
user-assigned part of a logical name. If you have multiple apps, you can use
separate logical names, which requires a custom JSON something like the
following.