cPanel Tomcat JSP and Servlets Guide
Sections
01. Installation
02. Structure
03. Versions
04. Logs
05. Processes
06. Tomcat manager
07. War files
08. Testing
09. Troubleshooting
10. Customizations
11. Miscellaneous issues
12. Disable
01. Installation of Tomcat and adding JSP support for a domain
a. Installation
To install Tomcat, select the Tomcat option in WHM’s EasyApache (Apache Update) or using “/scripts/easyapache” (without the quotes) in command line. The Tomcat selection is found in Step 5’s Apache Options area.
b. Adding servlet support
After Tomcat has been installed, use WHM > Account Functions > Install Servlets to add JSP and servlets to an account’s main domain. You can also do this using the following in shell:
Please replace domain.com with the domain name.
c. Subdomain servlet support
You would need to use command line for adding subdomain support for servlets as they do not automatically include that support and WHM does not have any option to add servlets to subdomains.
d. Addon domain servlet support
Addon domains will not work when added using command line if added by the addon domain name. The /usr/local/apache/conf/httpd.conf ServerName sub.domain.com line is what is used and it must match the Host name="sub.domain.com" line in /usr/local/jakarta/conf/server.xml file exactly, so addon domain support is added by installing servlets onto the subdomain associated with the addon domain:
e. Removing servlets
To remove JSP and servlets, only command line is available via this command:
02. Structure of the JSP and servlets installation
Tomcat places files into /usr/local/jakarta/tomcat which is symlinked from /usr/local/jakarta/apache-tomcat-# where # is the Tomcat version that was installed by EasyApache.
Here are the various files and folders:
/usr/local/jakarta/tomcat/conf/server.xml - Tomcat configuration file
/usr/local/jakarta/tomcat/bin - folder with Tomcat binaries such as startup.sh and shutdown.sh scripts
/usr/local/jakarta/tomcat/logs - folder with Tomcat log files
/usr/local/jakarta/tomcat/work/Catalina - folder for domains with servlet support that houses extracted .war files and other JSP content
03. Versions of Tomcat and Java
To see the Tomcat and JVM versions and paths, you can run the following in command line:
It outputs information such as the following:
If you only want to get the Java version, you can run:
It will show something like the following:
04. Logs
a. Tomcat logs
The Tomcat log files are at /usr/local/jakarta/tomcat/logs location. They are the following:
b. mod_jk logs and runtime file
The mod_jk error and warning log file is at /usr/local/apache/logs/mod_jk.log location.
Of note, the jk-runtime-status.pid# and jk-runtime-status.pid#.lock files are also located in /usr/local/apache/logs directory.
05. Processes and Restarting Tomcat Properly
When Tomcat is installed onto a machine, the following type of processes will show:
If you restart Tomcat using our service, we will not kill this process. The process needs to be killed manually (with “kill PID#” where PID# is the process number) before restarting our own Tomcat instance. If it isn’t, then Tomcat won’t function.
Of note, you can also restart Tomcat by calling “/usr/sbin/starttomcat” script, which is what our script calls.
06. Tomcat manager
a. Tomcat manager location
The Tomcat manager is at http://server.domain.com:8080/manager/html location (where server.domain.com is the machine’s hostname). Any domain on the server can also call this location via the same path.
b. Available options
Applications are listed in the manager with the ability to start, stop, reload and undeploy them there. War files can also be uploaded and deployed in the manager.
A Server Status section exists in Tomcat manager at http://server.domain.com:8080/manager/status
c. Authenticating
The username and password for accessing Tomcat manager is stored in /usr/local/jakarta/tomcat/conf/tomcat-users.xml file such as the following:
The manager is specifically the root user.
d. Giving another user access
Another user can be given access by adding an additional user line such as this example where the endar user is being added:
Tomcat would need to be restarted after making this change:
07. War files
a. Description
War files are archives containing the full JSP and servlet application. They are automatically extracted by Tomcat into /usr/local/jakarta/tomcat/work/Catalina/domain.com location (where domain.com is the domain name for the site) by the name of the .war file. For example, if you have hello.war file, then the extracted folder application will be /usr/local/jakarta/tomcat/work/Catalina/domain.com/hello
b. Tomcat versus Apache
When war files extract, they extract only in the Tomcat folder and not the user’s /home/username/public_html folder. Because they aren’t extracted there, Apache does not recognize the folder and the application will then only load at http://domain.com:8080/hello (using our prior example) and not at http://domain.com/hello
There has been some confusion that these are not automatically set to extract using our default entry in /usr/local/jakarta/tomcat/conf/server.xml but this is not the case. Our default setup does have these extract into /usr/local/jakarta/tomcat/work/Catalina/domain.com path.
Conversely, they will not show up on Apache under port 80 by default. Revising the server.xml also does not work for these to auto extract nor is that even necessary to do. The way to add servlet support and to get all extracted war files showing up under Apache is by adding these two lines to /home/username/public_html/.htaccess file:
I did this on my domain after adding sample.war to /home/endar/public_html (which then only extracted into /usr/local/jakarta/tomcat/work/Catalina/endar.org/sample folder), and after adding the lines I can access both Sample "Hello, World" Application and Sample "Hello, World" Application urls. That’s all it takes to get war files showing up under Apache.
The above lines also work for any servlet mapping where pages aren’t showing up in a browser with 404 errors for those pages even though the pages work when using the 8080 url.
c. war file testing
If war files appear not to be working, you can obtain a test war file at http://tomcat.apache.org/tomcat-5.5-doc/appdev/sample/sample.war and wget it to the account for deployment:
At that point, try to load the http://domain.com:8080/sample url in a browser. If it works, then war files are working regularly.
08. Testing
To test if a domain has JSP working, there is a default test page that should be installed when servlet support is originally added to the domain or subdomain. The test page should look like the following on the backend for the file contents:
The frontend would look like the following in a browser at http://domain.com/jsptest.jsp path:
Sample Application JSP Page
This is the output of a JSP page that is part of the Hello, World
application. It displays several useful values from the requestwe are
currently processing.
Request Method: GET
Servlet Path: /jsptest.jsp
If it does not look like this, then a different test page is being used. As such, copy the sample jsptest.jsp page at /usr/local/jakarta/apache-tomcat-5.5.35/samples/jsptest.jsp to the user’s account and check if it works:
Please replace username with the cPanel username above.
While Tomcat doesn’t really need to be restarted in this instance, doing so ensures that the account reloads. If the test page works and other pages still aren’t working, it is would be a coding issue.
09. Troubleshooting
a. Reinstalling Tomcat - last resort
In almost all instances, reinstalling Tomcat using EasyApache will not fix the issue with a page, pages, site or sites not working. Sometimes, a customized setup has been configured for Tomcat and reinstalling Tomcat will break all sites. Sometimes, the Tomcat version is older and, similar to Rails, newer Tomcat versions might not support the older coding, which will cause all sites to fail. As such, it is highly recommended to avoid reinstalling Tomcat unless absolutely necessary.
The only time reinstalling Tomcat has been beneficial was when the user ran out of disk space in /usr and had moved /usr/local to another directory. In that instance, the symlinks for java and tomcat services were pointing to files that no longer existed. Because of that, reinstalling Tomcat was required.
b. Coding configuration changes in WEB-INF on the account
The primary reason one account may not work for JSP is that coding has been placed into /home/username/public_html/WEB-INF that we did not provide and that coding, library or class is causing all pages to fail for JSP and servlets. This is easy to test.
First, here is what we provide on a default installation:
If there are any other files than these or content in the .htaccess besides what we provide, then any of those changes could be breaking JSP. Simply move the entire /home/username/public_html/WEB-INF directory to a backup and recreate it with only the contents we provide.
After making this change, restart Tomcat using “/usr/local/cpanel/scripts/restartsrv_tomcat” and check the jsptest.jsp page on the site in a browser again.
If the page works, then it is a coding issue.
c. Other reasons for JSP not working
In this guide, I previously discussed a few other reasons JSP and servlets might not be working:
- An addon domain rather than the subdomain was added for servlet support, and the Apache VirtualHost ServerName must match the domain being added to server.xml
- A non-cPanel Tomcat process is running due to issuing /usr/local/jakarta/tomcat/bin/startup.sh and that process needs to be killed, then /scripts/restartsrv_tomcat issued
- Servlet mapping hasn’t been added for war and other files and an .htaccess entry needs to be added for urls to work in Apache rather than showing a 404 Not Found error page
10. Customizations
a. server.xml configuration changes for Host entry
If you wish to customize the entries for Hosts (domains) in /usr/local/jakarta/tomcat/conf/server.xml file, then a TemplateToolkit file would be created at /var/cpanel/templates/tomcat/server.xml.host_entry.default (/var/cpanel/templates/tomcat folder needs to be created first and then the file). If this is not done, then any revisions will be wiped that are made directly to server.xml the next time servlets are added to another domain. The template file must be used in place of manually editing the server.xml file.
Here is one example of the contents that file could have:
This will create an entry that looks like the following for new servlets that are added in /usr/local/jakarta/tomcat/conf/server.xml file:
The old entry prior to adding this template would have been this instead:
After creating the file and to add it for all pre-existing users, you would issue this command:
This should restart Tomcat as well.
b. Java startup values
If you wish to change startup values for Heap size and others (you can see the settings that are configurable if you issue “java -X” without the quotes), then a file named /var/cpanel/tomcat.options could be created.
Here’s an example of entries that could be placed into the file:
This would change the maximum Java heap size (Xmx) and the initial Java heap size (Xms) on startup.
After this has been done, Tomcat would need to be restarted:
11. A few other reasons Tomcat might not be working
a. Disk space full and /usr moved
Tomcat will cease working when /usr/java is symlinked to /usr/local/jdk and /usr/local/jdk doesn't exist due to 100% disk space usage or /usr has been moved for that reason.
Here are the actual paths and file permissions for these files on a working machine:
b. public_html file permissions
On public_html, this needs to be 755 for Tomcat to access JSP and servlet files. A reboot can cause pages to cease working when public_html is set to 750. You'll see an error like the following in the /usr/local/jakarta/tomcat/logs/catalina.err error log file:
We have a touch file that disables the ability to start up tomcat:
If you add that file and then kill the Tomcat processes, “/scripts/restartsrv_tomcat” will no longer start up Tomcat. Check /usr/local/cpanel/scripts/restartsrv_tomcat to see the code for that.
Please note that this doesn't remove Tomcat. Currently, no script exists to remove it. When you uncheck it in EasyApache after it has been compiled onto the machine, the “Install Servlets” option still appears in WHM.
Sections
01. Installation
02. Structure
03. Versions
04. Logs
05. Processes
06. Tomcat manager
07. War files
08. Testing
09. Troubleshooting
10. Customizations
11. Miscellaneous issues
12. Disable
01. Installation of Tomcat and adding JSP support for a domain
a. Installation
To install Tomcat, select the Tomcat option in WHM’s EasyApache (Apache Update) or using “/scripts/easyapache” (without the quotes) in command line. The Tomcat selection is found in Step 5’s Apache Options area.
b. Adding servlet support
After Tomcat has been installed, use WHM > Account Functions > Install Servlets to add JSP and servlets to an account’s main domain. You can also do this using the following in shell:
Code:
/usr/local/cpanel/scripts/addservlets2 --domain=domain.comc. Subdomain servlet support
You would need to use command line for adding subdomain support for servlets as they do not automatically include that support and WHM does not have any option to add servlets to subdomains.
d. Addon domain servlet support
Addon domains will not work when added using command line if added by the addon domain name. The /usr/local/apache/conf/httpd.conf ServerName sub.domain.com line is what is used and it must match the Host name="sub.domain.com" line in /usr/local/jakarta/conf/server.xml file exactly, so addon domain support is added by installing servlets onto the subdomain associated with the addon domain:
Code:
/usr/local/cpanel/scripts/addservlets2 --domain=sub.domain.comTo remove JSP and servlets, only command line is available via this command:
Code:
/usr/local/cpanel/scripts/remservlets --domain=domain.comTomcat places files into /usr/local/jakarta/tomcat which is symlinked from /usr/local/jakarta/apache-tomcat-# where # is the Tomcat version that was installed by EasyApache.
Here are the various files and folders:
/usr/local/jakarta/tomcat/conf/server.xml - Tomcat configuration file
/usr/local/jakarta/tomcat/bin - folder with Tomcat binaries such as startup.sh and shutdown.sh scripts
/usr/local/jakarta/tomcat/logs - folder with Tomcat log files
/usr/local/jakarta/tomcat/work/Catalina - folder for domains with servlet support that houses extracted .war files and other JSP content
03. Versions of Tomcat and Java
To see the Tomcat and JVM versions and paths, you can run the following in command line:
Code:
/usr/local/jakarta/tomcat/bin/version.sh
Code:
[email protected] [/usr/local/jakarta/tomcat/bin]# ./version.sh
Using CATALINA_BASE: /usr/local/jakarta/tomcat
Using CATALINA_HOME: /usr/local/jakarta/tomcat
Using CATALINA_TMPDIR: /usr/local/jakarta/tomcat/temp
Using JRE_HOME: /usr/local/jdk
Using CLASSPATH: /usr/local/jakarta/tomcat/bin/bootstrap.jar
Server version: Apache Tomcat/5.5.35
Server built: Jan 6 2012 11:20:07
Server number: 5.5.35.0
OS Name: Linux
OS Version: 2.6.18-274.7.1.el5.028stab095.1
Architecture: amd64
JVM Version: 1.6.0_29-b11
JVM Vendor: Sun Microsystems Inc.
Code:
java -version
Code:
[email protected] [/usr/local/jakarta/tomcat/bin]# java -version
java version "1.6.0_29"
Java(TM) SE Runtime Environment (build 1.6.0_29-b11)
Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02, mixed mode)a. Tomcat logs
The Tomcat log files are at /usr/local/jakarta/tomcat/logs location. They are the following:
Code:
catalina.err - The Tomcat error log
catalina.out - The Tomcat process logThe mod_jk error and warning log file is at /usr/local/apache/logs/mod_jk.log location.
Of note, the jk-runtime-status.pid# and jk-runtime-status.pid#.lock files are also located in /usr/local/apache/logs directory.
05. Processes and Restarting Tomcat Properly
When Tomcat is installed onto a machine, the following type of processes will show:
If Tomcat is restarted manually without using our restart script at “/usr/local/cpanel/scripts/restartsrv_tomcat”, this type of process will show up instead:
This is done by issuing the following command:
Code:
/usr/local/jakarta/tomcat/bin/startup.shOf note, you can also restart Tomcat by calling “/usr/sbin/starttomcat” script, which is what our script calls.
06. Tomcat manager
a. Tomcat manager location
The Tomcat manager is at http://server.domain.com:8080/manager/html location (where server.domain.com is the machine’s hostname). Any domain on the server can also call this location via the same path.
b. Available options
Applications are listed in the manager with the ability to start, stop, reload and undeploy them there. War files can also be uploaded and deployed in the manager.
A Server Status section exists in Tomcat manager at http://server.domain.com:8080/manager/status
c. Authenticating
The username and password for accessing Tomcat manager is stored in /usr/local/jakarta/tomcat/conf/tomcat-users.xml file such as the following:
Code:
<tomcat-users>
<user name="tomcat" password="tomcat" roles="tomcat" />
<user name="role1" password="tomcat" roles="role1" />
<user name="both" password="tomcat" roles="tomcat,role1" />
<user name="root" password="dK08U9PbCcU1" roles="admin,manager" />
</tomcat-users>d. Giving another user access
Another user can be given access by adding an additional user line such as this example where the endar user is being added:
Code:
<tomcat-users>
<user name="tomcat" password="tomcat" roles="tomcat" />
<user name="role1" password="tomcat" roles="role1" />
<user name="both" password="tomcat" roles="tomcat,role1" />
<user name="root" password="dK08U9PbCcU1" roles="admin,manager" />
<user name="endar" password="[email protected]" roles="admin,manager" />
</tomcat-users>
Code:
/scripts/restartsrv_tomcata. Description
War files are archives containing the full JSP and servlet application. They are automatically extracted by Tomcat into /usr/local/jakarta/tomcat/work/Catalina/domain.com location (where domain.com is the domain name for the site) by the name of the .war file. For example, if you have hello.war file, then the extracted folder application will be /usr/local/jakarta/tomcat/work/Catalina/domain.com/hello
b. Tomcat versus Apache
When war files extract, they extract only in the Tomcat folder and not the user’s /home/username/public_html folder. Because they aren’t extracted there, Apache does not recognize the folder and the application will then only load at http://domain.com:8080/hello (using our prior example) and not at http://domain.com/hello
There has been some confusion that these are not automatically set to extract using our default entry in /usr/local/jakarta/tomcat/conf/server.xml but this is not the case. Our default setup does have these extract into /usr/local/jakarta/tomcat/work/Catalina/domain.com path.
Conversely, they will not show up on Apache under port 80 by default. Revising the server.xml also does not work for these to auto extract nor is that even necessary to do. The way to add servlet support and to get all extracted war files showing up under Apache is by adding these two lines to /home/username/public_html/.htaccess file:
Code:
SetHandler jakarta-servlet
SetEnv JK_WORKER_NAME ajp13The above lines also work for any servlet mapping where pages aren’t showing up in a browser with 404 errors for those pages even though the pages work when using the 8080 url.
c. war file testing
If war files appear not to be working, you can obtain a test war file at http://tomcat.apache.org/tomcat-5.5-doc/appdev/sample/sample.war and wget it to the account for deployment:
Code:
cd /home/username/public_html
wget http://tomcat.apache.org/tomcat-5.5-doc/appdev/sample/sample.war
chown username:username sample.war08. Testing
To test if a domain has JSP working, there is a default test page that should be installed when servlet support is originally added to the domain or subdomain. The test page should look like the following on the backend for the file contents:
Code:
<html><head><title>Test JSP page</title></head><body bgcolor=white>
<table border="0"><tr><td><h1>Sample Application JSP Page</h1>
This is the output of a JSP page that is part of the Hello, World application.
It displays several useful values from the requestwe are currently processing.</td></tr>
</table>
<table border="0" border="100%"><tr>
<th align="right">Request Method:</th>
<td align="left"><%= request.getMethod() %></td></tr><tr>
<th align="right">Servlet Path:</th>
<td align="left"><%= request.getServletPath() %></td></tr></table></body></html>Sample Application JSP Page
This is the output of a JSP page that is part of the Hello, World
application. It displays several useful values from the requestwe are
currently processing.
Request Method: GET
Servlet Path: /jsptest.jsp
If it does not look like this, then a different test page is being used. As such, copy the sample jsptest.jsp page at /usr/local/jakarta/apache-tomcat-5.5.35/samples/jsptest.jsp to the user’s account and check if it works:
Code:
cp /usr/local/jakarta/apache-tomcat-5.5.35/samples/jsptest.jsp /home/username/public_html
chown username:username /home/username/public_html/jsptest.jsp
/scripts/restartsrv_tomcatWhile Tomcat doesn’t really need to be restarted in this instance, doing so ensures that the account reloads. If the test page works and other pages still aren’t working, it is would be a coding issue.
09. Troubleshooting
a. Reinstalling Tomcat - last resort
In almost all instances, reinstalling Tomcat using EasyApache will not fix the issue with a page, pages, site or sites not working. Sometimes, a customized setup has been configured for Tomcat and reinstalling Tomcat will break all sites. Sometimes, the Tomcat version is older and, similar to Rails, newer Tomcat versions might not support the older coding, which will cause all sites to fail. As such, it is highly recommended to avoid reinstalling Tomcat unless absolutely necessary.
The only time reinstalling Tomcat has been beneficial was when the user ran out of disk space in /usr and had moved /usr/local to another directory. In that instance, the symlinks for java and tomcat services were pointing to files that no longer existed. Because of that, reinstalling Tomcat was required.
b. Coding configuration changes in WEB-INF on the account
The primary reason one account may not work for JSP is that coding has been placed into /home/username/public_html/WEB-INF that we did not provide and that coding, library or class is causing all pages to fail for JSP and servlets. This is easy to test.
First, here is what we provide on a default installation:
Code:
[email protected] [/home/endar/public_html/WEB-INF]# ls -lah
total 20K
drwxr-xr-x 4 endar endar 4.0K Jun 21 01:39 ./
drwxr-x--- 6 endar nobody 4.0K Jun 21 01:39 ../
drwxr-xr-x 2 endar endar 4.0K Jun 21 01:39 classes/
-rw-r--r-- 1 endar endar 14 Jun 21 01:39 .htaccess
drwxr-xr-x 2 endar endar 4.0K Jun 21 01:39 lib/
[email protected] [/home/endar/public_html/WEB-INF]# cat .htaccess
deny from all
[email protected] [/home/endar/public_html/WEB-INF/lib]# ls -lah
total 8.0K
drwxr-xr-x 2 endar endar 4.0K Jun 21 01:39 ./
drwxr-xr-x 4 endar endar 4.0K Jun 21 01:39 ../
[email protected] [/home/endar/public_html/WEB-INF/classes]# ls -lah
total 12K
drwxr-xr-x 2 endar endar 4.0K Jun 21 01:39 ./
drwxr-xr-x 4 endar endar 4.0K Jun 21 01:39 ../
-rw-r--r-- 1 endar endar 2.2K Jun 21 01:39 ServletsTestPage.classAfter making this change, restart Tomcat using “/usr/local/cpanel/scripts/restartsrv_tomcat” and check the jsptest.jsp page on the site in a browser again.
If the page works, then it is a coding issue.
c. Other reasons for JSP not working
In this guide, I previously discussed a few other reasons JSP and servlets might not be working:
- An addon domain rather than the subdomain was added for servlet support, and the Apache VirtualHost ServerName must match the domain being added to server.xml
- A non-cPanel Tomcat process is running due to issuing /usr/local/jakarta/tomcat/bin/startup.sh and that process needs to be killed, then /scripts/restartsrv_tomcat issued
- Servlet mapping hasn’t been added for war and other files and an .htaccess entry needs to be added for urls to work in Apache rather than showing a 404 Not Found error page
10. Customizations
a. server.xml configuration changes for Host entry
If you wish to customize the entries for Hosts (domains) in /usr/local/jakarta/tomcat/conf/server.xml file, then a TemplateToolkit file would be created at /var/cpanel/templates/tomcat/server.xml.host_entry.default (/var/cpanel/templates/tomcat folder needs to be created first and then the file). If this is not done, then any revisions will be wiped that are made directly to server.xml the next time servlets are added to another domain. The template file must be used in place of manually editing the server.xml file.
Here is one example of the contents that file could have:
Code:
<Host name="[% name %]" appBase="[% appbase %]"
unpackWARs="true" autoDeploy="true" xmlValidation="false"
xmlNamespaceAware="false" reloadable="true">
[%- FOREACH alias IN alias_list %]
<Alias>[% alias %]</Alias>
[% END -%]
<Context path="" reloadable="true" docBase="[% appbase %]" debug="0"
privileged="true" autoDeploy="true" liveDeploy="true"/>
<Context path="/manager" debug="0" privileged="true"
docBase="/usr/local/jakarta/tomcat/server/webapps/manager">
</Context>
</Host>
Code:
<Host name="domain.com" appBase="/home/username/public_html"
unpackWARs="true" autoDeploy="true" xmlValidation="false"
xmlNamespaceAware="false" reloadable="true">
<Alias>www.domain.com</Alias>
<Context path="" reloadable="true" docBase="/home/username/public_html" debug="0"
privileged="true" autoDeploy="true" liveDeploy="true"/>
<Context path="/manager" debug="0" privileged="true"
docBase="/usr/local/jakarta/tomcat/server/webapps/manager">
</Context>
</Host>
Code:
<Host name="domain.com" appBase="/home/username/public_html">
<Alias>www.domain.com</Alias>
<Context path="" reloadable="true" docBase="/home/username/public_html" debug="1"/>
<Context path="/manager" debug="0" privileged="true"
docBase="/usr/local/jakarta/tomcat/server/webapps/manager">
</Context>
</Host>
Code:
/usr/local/cpanel/scripts/gentomcatlistb. Java startup values
If you wish to change startup values for Heap size and others (you can see the settings that are configurable if you issue “java -X” without the quotes), then a file named /var/cpanel/tomcat.options could be created.
Here’s an example of entries that could be placed into the file:
Code:
-Xmx200M
-Xms100MAfter this has been done, Tomcat would need to be restarted:
Code:
/scripts/restartsrv_tomcata. Disk space full and /usr moved
Tomcat will cease working when /usr/java is symlinked to /usr/local/jdk and /usr/local/jdk doesn't exist due to 100% disk space usage or /usr has been moved for that reason.
Here are the actual paths and file permissions for these files on a working machine:
Code:
[email protected] [/usr/local/jakarta/tomcat/conf]# ls -lah /usr/local/jdk
lrwxrwxrwx 1 root root 22 Jun 21 00:19 /usr/local/jdk -> /usr/local/jdk1.6.0_29/
[email protected] [/usr/local/jakarta/tomcat/conf]# ls -lah /usr/local/jre
lrwxrwxrwx 1 root root 18 Jun 21 00:20 /usr/local/jre -> /usr/local/jdk/jre/
[email protected] [/usr]# ls -lah java*
lrwxrwxrwx 1 root root 14 Jun 21 00:34 java -> /usr/local/jdk/
[email protected] [/usr/share]# ls -ld java
drwxr-xr-x 3 root root 4096 May 4 20:54 java/
[email protected] [/usr/share]# ls -ld /usr/local/jdk1.6.0_29/
drwxr-xr-x 10 root root 4096 Jun 21 00:19 /usr/local/jdk1.6.0_29//
[email protected] [/usr/share]# ls -ld /usr/local/jdk/jre
drwxr-xr-x 7 root root 4096 Jun 21 00:19 /usr/local/jdk/jre/On public_html, this needs to be 755 for Tomcat to access JSP and servlet files. A reboot can cause pages to cease working when public_html is set to 750. You'll see an error like the following in the /usr/local/jakarta/tomcat/logs/catalina.err error log file:
12. Disabling Tomcat
We have a touch file that disables the ability to start up tomcat:
Code:
/etc/tomcatdisablePlease note that this doesn't remove Tomcat. Currently, no script exists to remove it. When you uncheck it in EasyApache after it has been compiled onto the machine, the “Install Servlets” option still appears in WHM.
