From Apis Networks Wiki

Contents 1 Overview 1.1 Current Java version 1.2 Current Tomcat version 2 Tomcat 2.1 Bouncing Tomcat 2.2 Where is the Tomcat logfile located? 2.3 Reloading a Context/Application 3 Running the JVM 3.1 Problems 3.1.1 java/javac and libjni.so error message 3.1.2 INSTALL4J_JAVA_HOME

Overview

Current Java version

At this time the servers are running Java6

Current Tomcat version

At this time the servers are running Tomcat 5

Tomcat

Bouncing Tomcat

As the main user of the account create a file named tomcat inside your home directory.  The following command will force a restart within 5 minutes,

touch ~/tomcat

Home directories are polled every 5 minutes for a restart; please do not request a smaller delay as frequent restarts may be disruptive to others.

Where is the Tomcat logfile located?

Tomcat's logfile is named catalina.out inside /var/log/.

Reloading a Context/Application

Often times it is necessary to reload a context after making changes to a configuration file like web.xml. Tomcat will automatically reload a context if the modification time on a jar, war, or class file has changed. Any other changes will not result in a context reload. You may force a reload by updating the timestamp of a jar, war, or class file within the WEB-APPS/ directory; this is typically done with touch utility:

cd /var/www/html/WEB-APPS/
touch lib/somejar.jar

Note: A severe exception within the context will force the context to be dropped by Tomcat. See the subsequent item on restarting Tomcat in the case of a severe exception. Once a severe exception occurs your context is no longer valid unless Tomcat is bounced.

Running the JVM

Problems

java/javac and libjni.so error message

When attempting to use the java/javac binaries from the shell without procfs mounted, the server will produce the following error message:

java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory

Login to the control panel and visit Language Options -> Mount procfs to mount procfs and fix the problem.

The root cause of the error message is that java/javac binaries in Java6 poke around procfs to determine the current working directory. After ascertaining the cwd, Java loads the libjni.so library by taking the path and descending two directories to locate the libjni.so directory. An strace better explains the behavior:

Without procfs mounted: execve("/usr/bin/java", ["java"], [/* 29 vars */]) = 0 brk(0) = 0x8053000 readlink("/proc/self/exe", 0xbfd64048, 4096) = -1 ENOENT (No such file or directory) ... open("libjli.so", O_RDONLY) = -1 ENOENT (No such file or directory)

With procfs mounted: execve("/usr/bin/java", ["java"], [/* 29 vars */]) = 0 brk(0) = 0x8053000 readlink("/proc/self/exe", "/usr/java/jdk1.6.0/bin/java", 4096) = 27 ... stat64("/usr/java/jdk1.6.0/bin/../jre/lib/i386/jli", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0

INSTALL4J_JAVA_HOME

No suitable Java Virtual Machine could be found on your system. The version of the JVM must be at least 1.5 and at most 1.6. Please define INSTALL4J_JAVA_HOME to point to a suitable JVM. You can also try to delete the JVM cache file $HOME/.install4j

This error message occurs from an undefined INSTALL4J_JAVA_HOME location. INSTALL4J_JAVA_HOME may be defined from the shell by executing the following command:

declare INSTALL4J_JAVA_HOME="/usr/java/default"

declare makes the variable available to processes executed from within the shell. The command may be automatically run at login by placing it inside .bash_profile within the user's home directory.