Self-Managed JVM Guide

This page contains information about how to manage your Self-Managed Tomcat, JBoss, Geronimo or Command-Line JVM.

Initial Configuration Backup

Metawerx will pre-install the container version of your choice. You will have access to the entire folder structure, which means you will also have the power to damage the installation, and prevent your VM from restarting.

Therefore, the first thing you should do, is back up the configuration files, so that you can restore them if you accidentally break the installation.

These files are modified by Metawerx, and are specific to your installation. They contain details such as your IP address and username/password. All other files are the default installation files, according to whichever software and version you selected.

Tomcat:

• /bin/setclasspath.sh
• /conf/server.xml
• /conf/tomcat-users.xml

JBoss/Geronimo:

• entire config folder

Command Line Applications:

• (no backup necessary, no config files are stored in your folder)

Removing Sample Applications

After verifying your setup, you should erase all example applications that come with Tomcat, JBoss or Geronimo. These take unnecessary space and other system resources. Note that in some cases Metawerx will remove these for you during the setup process.

System Logs

System out (stdout) and system error (stderr) logs will appear in your root folder. These will be date-stamped according to the time they were created.

You can also access the current log from within SiteWinder, under the System Logs option on the Tools page. SiteWinder sends the log files in a compressed format directly to your browser, allowing quick access to the current log for debugging purposes.

Manually restarting your VM

You can restart your VM from within Tomcat, on the tools page.

Please ensure that if you change any VM configuration files which may prevent the VM from starting up correctly, that you wait for the restart to complete successfully and ensure it is running properly. If the VM fails to restart, Metawerx Support will be sent an alert by email and SMS. This process will continue indefinitely until you repair the configuration (which as you can imagine, can be quite worrying for the support staff).

Tomcat Root Path

Your root path is /cust/YOUR_LOGIN_NAME/home.

For Tomcat, your ROOT application's root path will be /cust/YOUR_LOGIN_NAME/home/webapps/ROOT.

Where should I upload my application(s)?

A self managed Tomcat, JBoss or Geronimo installation has a folder layout identical to if you download Tomcat, JBoss or Geronimo yourself. Therefore, your applications should be uploaded in the /webapps folder.

You will find the default ROOT application in /webapps/ROOT. To install other applications, simply add WAR files to the /webapps folder, or unpacked applications to /webapps/APPLICATION_NAME.

The ROOT Application is accessible over the internet as http://www.yourdomain.com, or http://tcNNNN.metawerx.com.au, where NNNN is the customer number you have been assigned by Metawerx.

Other applications, such as one called MyOtherApp, are installed as /webapps/MyOtherApp, and are accessible as http://www.yourdomain.com/MyOtherApp

How can I add extra domains with separate websites?

If you add extra domain names, and want them to point to separate websites, you will need to add extra <Host> entries in server.xml. In this case, you will need to set the appBase folder attribute in the <Host> element accordingly. The appBase folder you set should exist within your home folder, which is /cust/YOUR_LOGIN_NAME/home.

In the <Host> element in server.xml, the appBase is relative to /cust/YOUR_LOGIN_NAME/home. The default Tomcat <Host> entry looks like this (note the appBase="webapps" attribute):

<Host name="localhost" appBase="webapps"
  unpackWARs="true" autoDeploy="true"
  xmlValidation="false" xmlNamespaceAware="false">

Therefore, you could easily add a second domain called www.myotherdomain.com, using the following Host entry:

<Host name="www.myotherdomain.com" appBase="webapps_myotherdomain"
  unpackWARs="true" autoDeploy="true"
  xmlValidation="false" xmlNamespaceAware="false">

In this case, the webapps folder for your new domain would be /cust/YOUR_LOGIN_NAME/home/webapps_myotherdomain, and the ROOT application for that domain would be located in /cust/YOUR_LOGIN_NAME/home/webapps_myotherdomain/ROOT.

You could also set the path explicitly, as follows, which has the same effect:

<Host name="www.myotherdomain.com" appBase="/cust/YOUR_LOGIN_NAME/home/webapps_myotherdomain"
  unpackWARs="true" autoDeploy="true"
  xmlValidation="false" xmlNamespaceAware="false">

We recommend that you use a relative path however, as in the first example, in case we ever need to relocate your base folder.