'tomcat'에 해당되는 글 16건

  1. 2012.04.10 Tomcat 관련 Articles.
  2. 2012.03.21 apache, tomcat 링크모음.
  3. 2012.02.28 Tomcat lb 를 이용해서 Weighted 구현하기.
  4. 2012.02.28 Tomcat 6.0.35 Session Clustering
  5. 2008.07.30 apache+tomcat+jdk 설치 및 연동 1
  6. 2008.07.29 [펌]Tomcat configuration

Tomcat 관련 Articles.

ITWeb/서버관리 2012. 4. 10. 16:39

사이트에 잘 정리가 되어 있내요.
도움이 될 것 같아 bookmarking 해봅니다..

[원본링크]

[원본글]

Apache Tomcat Resource Center

This page provides free Apache Tomcat resources that will help you identify, troubleshoot, and resolve common problems with Apache Tomcat.

Apache Tomcat is the world's most widely used web application server, with over one million downloads per month and over 70% penetration in the enterprise datacenter. Tomcat is used to power everything from simple one server sites to large enterprise networks.

Tomcat Installation And Configuration

Apache Tomcat Performance

Tomcat How-To Guides

Apache Tomcat Components

Apache Tomcat In Development

More Tomcat Resources

Tomcat Monitoring and Administration

Apache Tomcat On Your OS

Tomcat Versions

Troubleshooting Tomcat

Improving Tomcat Security

Still haven't found what you are looking for? Visit our free email-based Tomcat support line!

:

apache, tomcat 링크모음.

ITWeb/서버관리 2012. 3. 21. 16:11
:

Tomcat lb 를 이용해서 Weighted 구현하기.

ITWeb/서버관리 2012. 2. 28. 17:36
[Tomcat Load Balancer 로 Weighted 구현]

ps=/

#worker.list=tomcat1, tomcat2, loadBalancer

worker.list=loadBalancer


worker.tomcat1.port=8009

worker.tomcat1.host=10.67.8.113

worker.tomcat1.type=ajp13

worker.tomcat1.lbfactor=2   # tomcat1 이 2번


worker.tomcat2.port=8109

worker.tomcat2.host=10.67.8.113

worker.tomcat2.type=ajp13

worker.tomcat2.lbfactor=1   # tomcat2 가 1번 씩 번갈아 가면서 호출 됩니다.


worker.loadBalancer.type=lb

worker.loadBalancer.method=T

worker.loadBalancer.balance_workers=tomcat1,tomcat2

worker.loadBalancer.sticky_session=0



※ 이전에 작성한 글들 참고하세요.
http://jjeong.tistory.com/581 : httpd mod_proxy 를 이용한 load balancing
http://jjeong.tistory.com/580 : Tomcat Session Clustering

[참고정보]
http://tomcat.apache.org/connectors-doc/generic_howto/workers.html 
http://tomcat.apache.org/connectors-doc/reference/workers.html 

DirectiveDefaultDescription
balance_workers - A comma separated list of workers that the load balancer need to manage.

This directive can be used multiple times for the same load balancer.

This directive replaces old balanced_workers directive and can be used only with mod_jk versions 1.2.7 and up.

As long as these workers should only be used via the load balancer worker, there is no need to also put them into the worker.list property.

sticky_session True Specifies whether requests with SESSION ID's should be routed back to the same Tomcat worker. If sticky_session is set to True or 1sessions are sticky, otherwise sticky_session is set to False. Set sticky_session to False when Tomcat is using a Session Manager which can persist session data across multiple instances of Tomcat.
sticky_session_force False Specifies whether requests with SESSION ID's for workers that are in error state should be rejected. If sticky_session_force is set to True or1 and the worker that matches that SESSION ID is in error state, client will receive 500 (Server Error). If set to False or 0 failover on another worker will be issued with loosing client session. This directive is used only when you set sticky_session=True.

This feature has been added in jk 1.2.9.

method Request Specifies what method load balancer is using for electing the best worker. Please note, that session stickiness and perfect load balancing are conflicting targets, especially when the number of sessions is small, or the usage of sessions is extremely varying For huge numbers of sessions this usually is not a problem.

Some methods note, that they aggregate in a sliding time window. They add up accesses, and on each run of the global maintain method, the load counters get divided by 2. Usually this happens once a minute, depending on the setting of worker.maintain. The value of the load counters can be inspected using the status worker.

If method is set to R[equest] the balancer will use number of requests to find the best worker. Accesses will be distributed according to the lbfactor in a sliding time window. This is the default value and should be working well for most applications.

If method is set to S[ession] the balancer will use number of sessions to find the best worker. Accesses will be distributed according to the lbfactor in a sliding time window. Because the balancer does not keep any state, it actually does not know the number of sessions. Instead it counts each request without a session cookie or URL encoding as a new session. This method will neither know, when a session is being invalidated, nor will it correct its load numbers according to session timeouts or worker failover. This method should be used, if sessions are your limiting resource, e.g. when you only have limited memory and your sessions need a lot of memory.

If set to T[raffic] the balancer will use the network traffic between JK and Tomcat to find the best worker. Accesses will be distributed according to the lbfactor in a sliding time window. This method should be used, if network to and from the backends is your limiting resource.

If set to B[usyness] the balancer will pick the worker with the lowest current load, based on how many requests the worker is currently serving. This number is divided by the workers lbfactor, and the lowest value (least busy) worker is picked. This method is especially interesting, if your request take a long time to process, like for a download application.

This feature has been added in jk 1.2.9. The Session method has been added in jk 1.2.20.

lock Optimistic Specifies what lock method the load balancer will use for synchronising shared memory runtime data. If lock is set to O[ptimistic] balancer will not use shared memory lock to find the best worker. If set toP[essimistic] balancer will use shared memory lock. The balancer will work more accurately in case of Pessimistic locking, but can slow down the average response time.

This feature has been added in jk 1.2.13.

retries 2

This directive also exists for normal workers. For those it has adifferent meaning.

If the load balancer can not get a valid member worker or in case of failover, it will try again a number of times given by retries. Before each retry, it will make a pause define by retry_interval directive.

Until version 1.2.16 the default value was 3.

 
:

Tomcat 6.0.35 Session Clustering

ITWeb/서버관리 2012. 2. 28. 11:09
Tomcat 6.0.35 Session Clustering 


[준비사항]

- Apache 2.4.1 다운로드 받기 : http://httpd.apache.org/download.cgi#apache24

- Tomcat 6.0.35 다운로드 받기 : http://mirror.khlug.org/apache/tomcat/tomcat-6/v6.0.35/bin/apache-tomcat-6.0.35.zip

- Tomcat Connecter 다운로드 받기 : http://ftp.daum.net/apache//tomcat/tomcat-connectors/jk/tomcat-connectors-1.2.32-src.zip

- 다운로드 링크가 깨졌다면 해당 사이트에 직접 다운로드 받으시면 됩니다.


[설치]

- Windows 에 설치 하는 것이기 때문에 대부분 압축만 푸시고 적당한 위치에 가져다 놓으시면 됩니다.
- 편의상 D:\Application\ 아래 놓도록 하겠습니다.
- 그 이외 자세한 설치 방법은 제 블로그 이전 글 참고 하시면 됩니다. (linux 버전이지만 참고 정도는 됩니다. ^^;)
- httpd 설치 : http://jjeong.tistory.com/421
- tomcat 설치 : http://jjeong.tistory.com/435
- tomcat connector 설치 : http://jjeong.tistory.com/433
- httpd+tomcat+jdk 연동 : http://jjeong.tistory.com/230

 
[설정]

- httpd 설정하기
httpd 가 설치된 경로에서 conf 폴더에 있는 httpd.conf 파일을 에디터창에서 수정.

# 이 설정에 주석을 제거해 줍니다.
# 이유는 httpd 의 proxy balancer 기능을 이용하기 위해서 입니다.
# tomcat 의 경우 기본 worker 설정에서 type 을 lb 로 지정해 주면 httpd 관계 없이 loadbalancer 기능을 이용 할 수 있습니다. 
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_ajp_module modules/mod_proxy_ajp.so
LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so

# 이 설정에 주석을 제거해 줍니다.
Include conf/extra/httpd-vhosts.conf

# 아래 파일을 include 해 줍니다.
Include D:/Application/httpd/conf/session-cluster/tomcat.conf

 
[httpd-vhost.conf 설정하기]

<VirtualHost dev.session-cluster.com:80>
    ServerAdmin jjeong@tistory.com
    DocumentRoot "D:\Application\httpd\htdocs\session_cluster\web"
    ServerName dev.session-cluster.com
    ServerAlias dev.session-cluster.com
    ErrorLog "D:\Application\httpd\logs\dev.session-cluster.com-error.log"
    CustomLog "D:\Application\httpd\logs\dev.session-cluster.com-access.log" common
jkMount /* loadBalancer
DirectoryIndex index.html index.jsp

<Directory "D:\Application\httpd\htdocs\session_cluster\web">
Options FollowSymLinks
AllowOverride None
Order allow,deny
Allow from All
</Directory>
</VirtualHost>

 
[tomcat.conf 설정하기]

LoadModule jk_module modules/mod_jk.so

JkWorkersFile            D:/Application/httpd/conf/session-cluster/workers.properties
JkShmFile               D:/Application/httpd/logs/mod_jk.shm
JkLogFile                D:/Application/httpd/logs/mod_jk.log
JkLogLevel               debug
JkLogStampFormat      "[%a %b %d %H:%M:%S %Y] "
JkRequestLogFormat   "%w %V %T"

 
[workers.properties 설정하기]

ps=/
worker.list=tomcat1, tomcat2, loadBalancer

worker.tomcat1.port=8009
worker.tomcat1.host=localhost
worker.tomcat1.type=ajp13
worker.tomcat1.lbfactor=1

worker.tomcat2.port=8109
worker.tomcat2.host=localhost
worker.tomcat2.type=ajp13
worker.tomcat2.lbfactor=1

worker.loadBalancer.type=lb
worker.loadBalancer.balanced_workers=tomcat1,tomcat2
worker.loadBalancer.sticky_session=1

 
[Tomcat1 server.xml 설정하기]

- 파일을 열어 보시면 <Cluster /> 섹션이 있습니다.
- 주석 처리 되어 있는 부분을 해제 합니다.
<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"/>
- <Engine /> 섹션에 jvmRoute 코드 추가 합니다.
<Engine defaultHost="localhost" jvmRoute="tomcat1" name="Catalina">

이전 버전과 다른 점은 
previous : org.apache.catalina.cluster.tcp.SimpleTcpCluster
current : org.apache.catalina.ha.tcp.SimpleTcpCluster
해당 패키지의 경로 입니다.

 
[Tomcat2 server.xml 설정하기]

- Tomcat1 설정과 동일하게 주석을 제거 합니다.
- <Engine /> 섹션에 jvmRoute 코드 추가 합니다.
<Engine defaultHost="localhost" jvmRoute="tomcat2" name="Catalina">

 
[Tomcat1, Tomcat2 서버의 web.xml 설정하기]

- 설정 파일 제일 하단에 아래 코드 추가 합니다.
<distributable />

 
[Tomcat 설정 시 주의사항]

- 위 설정들은 PC 한 대에서 설정하는 내용으로 기술을 하였습니다.
- 각 port 충돌이 발생 하지 않도록 주의 하시기 바랍니다.

 
[Tomcat1 서버의 index.jsp]

<%
  session.setAttribute("a","a");
%>
<html>
<head>
<title>Test JSP</title>
</head>

<body>
<table width="100%" border="0" cellspacing="0" cellpadding="0">
  <tr bgcolor="#CCCCCC">
    <td width="13%">Tomcat1 Machine</td>
    <td width="87%">&nbsp;</td>
  </tr>
  <tr>
    <td>Session ID :</td>
    <td><%=session.getId()%></td>
  </tr>
</table>
</body>
</html>


 
 
[Tomcat2 서버의 index.jsp]

<%
  session.setAttribute("a","a");
%>
<html>
<head>
<title>Test JSP</title>
</head>

<body>
<table width="100%" border="0" cellspacing="0" cellpadding="0">
  <tr bgcolor="#CCCCCC">
    <td width="13%">Tomcat2 Machine</td>
    <td width="87%">&nbsp;</td>
  </tr>
  <tr>
    <td>Session ID :</td>
    <td><%=session.getId()%></td>
  </tr>
</table>
</body>
</html>




Eclipse 에서 Tomcat1, 2 를 번갈아 가면서 start, stop 해 보시면 lb 동작 하는걸 확인 하실 수 있습니다.
그리고 session 유지 되는 것도 확인 가능 합니다.
 
[Eclipse 에서 Tomcat 서버 등록 및 실행하기]

- Server 창에서 New -> Server -> Apache -> Tomcat v6.0 Server 선택
- Server name 에 Tomcat Session Cluster 1 이라고 작성
- Next 버튼 클릭 또는 Server runtime environment 에서 Add 클릭
- Browse 버튼 클릭 후 설치된 Tomcat1 서버의 경로를 지정 합니다.
- 이런 방식으로 Tomcat2 서버도 등록을 합니다.


 

[참고사이트]
http://www.easywayserver.com/implementation-tomcat-clustering.htm
http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html


※ 위 내용은 성능 튜닝을 고려하지 않은 내용입니다.
실제 서비스에 적용하시기 전에 충분한 튜닝 과정을 거치시기 바랍니다.

※ 서버 한대를 기준으로 설정한 내용입니다.
서버 여러대를 묶기 위해서는 <Cluster /> 섹션에 추가 설정을 해줘야 합니다.
이 부분은 추후 작성 업데이트 하겠습니다.  

 
:

apache+tomcat+jdk 설치 및 연동

ITWeb/서버관리 2008. 7. 30. 12:38

Download
* http://java.sun.com/javase/downloads/index_jdk5.jsp
JDK 5.0 Update 16 다운로드 받음
http://java.sun.com/j2se/1.5.0/install-linux.html

* http://httpd.apache.org/download.cgi
httpd-2.2.9.tar.gz

* http://tomcat.apache.org/
apache-tomcat-6.0.16.tar.gz

* http://tomcat.apache.org/connectors-doc/
tomcat-connectors-1.2.26-src.tar.gz
mod_jk-1.2.26-httpd-2.2.6.so

Installation
* JDK 설치
download 경로 및 설치 시작 위치 : /home/app/download/
설치 경로 : /home/app/java/jdk
설치하기
파일권한변경
$ /home/app/download/]chmod 744 jdk-1_5_0_16-linux-i586.bin
$ /home/app/download/]./jdk-1_5_0_16-linux-i586.bin
약관같은 내용 스킵(q 누르고 빠져 나옴)
yes 입력후 설치 시작
$ /home/app/download/]cd jdk1.5.xxx
$ /home/app/download/]mv -f * /home/app/java/jdk
$ /home/app/download/]cd ..
$ /home/app/download/]rm -rf ./jdk1.5.xxx
JAVA_HOME 과 path 설정
.cshrc 기준
setenv JAVA_HOME "/home/app/java/jdk"
set path=( $path $JAVA_HOME/bin )

기 설치된 java 삭제 (rpm 설치)
설치 pkg 확인 (root 로 실행)
삭제 및 java version 확인
$ /home/app/download/]rpm -qif /usr/lib/jvm/jre-1.4.2-gcj/bin/java
$ /home/app/download/]rpm -e java-1.4.2-gcj-compat
$ /home/app/download/]java -version

* tomcat 설치
$ /home/app/download/] tar -xvzf apache-tomcat-6.0.16.tar.gz
$ /home/app/download/]mv -f ./apache-tomcat-6.0.16 ../tomcat

.cshrc 기준
setenv CATALINA_HOME "/home/app/tomcat"
set path=( $path $CATALINA_HOME/bin )

tomcat 설치 테스트
$ /home/app/tomcat/bin]startup.sh

http://localhost:8080/

* apache 설치
# jsp 를 사용하기 땜시 기본 설치 합니다.
$ /home/app/download/httpd-2.2.9]./configure --prefix=/home1/irteam/naver/apache-2.2.9 --enable-so --with-mpm=worker
$ /home/app/download/httpd-2.2.9]make clean
$ /home/app/download/httpd-2.2.9]make
$ /home/app/download/httpd-2.2.9]make install

* apache tomcat connector
apache 와 tomcat 을 연동하기 위해서 설치
ref. ttp://tomcat.apache.org/connectors-doc/webserver_howto/apache.html
ref. http://www.akadia.com/download/soug/tomcat/html/tomcat_apache.html

    • source build 하기
      tar -xvzf tomcat-connectors-1.2.26-src.tar.gz
      cd tomcat-connectors-1.2.26-src/native
      ./buildconf.sh
      ./configure --with-apxs=/home/app/apache-2.2.9/bin/apxs ## <-- apxs 가 설치된 위치 지정
      make
      make install
      cd apache-2.0 ## <-- 들어가 보시면 mod_jk.so 가 생성되어 있습니다. apache 설치 경로의 ~/modules/ 아래 보시면 mod_jk.so 가 복사되어 있지 않으면 복사해서 넣기
    • httpd.conf 수정하기
      # tomcat.conf 설정은 LoadModule 설정 최상단에 위치
      # apache module load 순서와 연관
      include conf/tomcat.conf
      include extra/httpd-vhost.conf
    • tomcat.conf 수정하기
      # JkMount 와 같은 option 들은 virtualhost 설정에서 잡아주고 
      # 아래는 공통 설정
      LoadModule jk_module modules/mod_jk.so
      
      JkWorkersFile           conf/workers.properties
      JkShmFile               /home/app/logs/apache/mod_jk.shm
      JkLogFile               /home1/app/logs/apache/mod_jk.log
      JkLogLevel              debug
      JkLogStampFormat        "[%a %b %d %H:%M:%S %Y] "
      JkRequestLogFormat  "%w %V %T"
    • workers.properties 수정하기
      workers.tomcat_home=/home/app/tomcat
      workers.java_home=/home/app/java/jdk
      
      ps=/
      worker.list=tebs ## <-- tebs 는 property 또는 서비스 명
      
      worker.tebs.port=8009
      worker.tebs.host=localhost
      worker.tebs.type=ajp13
      worker.tebs.lbfactor=1
    • extra/httpd-vhost.conf 수정하기
      NameVirtualHost *
      
      #
      # VirtualHost example:
      # Almost any Apache directive may go into a VirtualHost container.
      # The first VirtualHost section is used for all requests that do not
      # match a ServerName or ServerAlias in any <VirtualHost> block.
      #
      <VirtualHost *>
          ServerName localhost
          ServerAlias localhost
          ServerAdmin admin@localhost
          DocumentRoot "/home/app/docs/tebs/web"
      
          ErrorLog "/home/app/logs/apache/error"
          CustomLog "/home/app/logs/apache/access" common
      
          JkMount             /*.jsp  tebs # 또는 /* tebs
      
      # htdocs 위치는 아래와 같음.
          <Directory "/home/app/docs/tebs/web">
              AllowOverride None
              Order deny,allow
              Allow from all
          </Directory>
      # 접근 금지
          <Directory "/home/app/docs/tebs/web/WEB-INF">
              AllowOverride None
              Order deny,allow
              Deny from all
              Allow from none
          </Directory>
      # 접근 금지
          <Directory "/home/app/docs/tebs/web/META-INF">
              AllowOverride None
              Order deny,allow
              Deny from all
              Allow from none
          </Directory>
      </VirtualHost>
    • server.xml 수정
      # 위치는 tomcat 설치 위치의 /home/app/tomcat/conf/server.xml
      # 기본 tomcat context root 변경을 위해서 아래와 같이 apache htdocs 설정한 경로로 변경
      <Host name="localhost"  appBase="/home/app/docs/tebs/web"
                  unpackWARs="true" autoDeploy="true"
                  xmlValidation="false" xmlNamespaceAware="false">
              <Context path="" docBase="." debug="0" reloadable="true"></Context>
      </Host>
    • jsp 파일 테스트

      아래 apache 와 tomcat 의 실행 순서 매우 중요
      tomcat daemon 이 먼저 떠 있어야 mod_jk 가 apache 모듈로 load 될때 정상적으로 connect 할 수 있음
      아파치설치경로/bin/apachectl stop
      톰켓설치경로/bin/shutdown.sh
      톰켓설치경로/bin/startup.sh
      아파치설치경로/bin/apachectl start
      # htdocs 로 이동
      cd /home/app/tomcat/webapps/ROOT // 또는 /home/app/tomcat/webapps서비스명 또는 프로젝트명/
      vi index.jsp
      # 브라우저에서 접속 테스트




 






 

:

[펌]Tomcat configuration

ITWeb/서버관리 2008. 7. 29. 10:32

ref. http://www.akadia.com/download/soug/tomcat/html/tomcat_apache.html

Tomcat Configuration

The Tomcat server.xml file allows you to configure Tomcat using a simple XML descriptor. This XML file is at the heart of Tomcat.

The <Context> element is the most commonly used element in the server.xml file. It represents an individual Web Application that is running within a defined <Host>. There is no limit to the number of contexts that can be defined within a <Host> element. Each <Context> definition must have a unique context path, which is defined by the path attribute.

1. Creating the Web Application Context (Location of the Web Application):

<!-- Tomcat Root Context -->
<Context path="/jsp" docBase="/www/webapp/jsp" debug="0" reloadable="false" />

  • docBase: Defines the directory for the Web application associated with this <Context>. This is the pathname of a directory that contains the resources for the Web application.

  • path: Defines the context path for this Web application. This value must be unique for each <Context> defined in a given <Host>.

  • reloadable: If set to true, causes Tomcat to check for class changes in the WEB-INF/classes/ and WEB-INF/lib directories. If these classes have changed, the application owning these classes will automatically be reloaded. This feature should only be used during development. This setting will cause severe performance degradation, and therefore should be set to false when in a production environment.

2. Disable Port 8080 (Port 8080 is only used in stand-alone mode)

<!-- Define a non-SSL Coyote HTTP/1.1 Connector on port 8080 -->
<!-- (Uncommented for Productive Environment)

<Connector className="org.apache.coyote.tomcat4.CoyoteConnector"
port="8080" minProcessors="5" maxProcessors="75"
enableLookups="true" redirectPort="8443"
acceptCount="10" debug="0" connectionTimeout="20000"
useURIValidationHack="false" />
-->


Creating the Web Application Directory Structure

The container that holds the components of a web application is the directory structure in which it exists. The first step in creating a web application is creating this structure. The following table contains the sample web application and what each of its directories should contain.

The Web Application Directory Structure (Example)

Directory

Contains

/www/webapp/jsp

This is the root directory of the web application. All JSP and XHTML files are stored here.

/www/webapp/jsp/WEB-INF

This directory contains all resources related to the application that are not in the document root of the application. This is where your web application deployment descriptor is located. Note that the WEB-INF directory is not part of the public document. No files contained in this directory can be served directly to a client.

/www/webapp/jsp/WEB-INF/classes

This directory is where servlet and utility classes are located.

/www/webapp/jsp/WEB-INF/lib

This directory contains Java Archive files that the web application depends upon. For example, this is where you would place a JAR file that contained a JDBC driver.



Add a servlet entry into the web application's web.xml file

If you are deploying a servlet, then you have to add a servlet entry into the web application's web.xml file. An example <servlet> element can be found in the following code snippet.

<servlet>
  <servlet-name>MyServlet</servlet-name>
  <servlet-class>packagename.MyServlet</servlet-class>
  <init-param>
    <param-name>parameter</param-name>
    <param-value>value</param-value>
  </init-param>
  <load-on-startup>1</load-on-startup>
</servlet>

It isn't necessary to add all servlets to the web.xml file; it's only necessary when the servlet requires additional information, such as initialization parameters.

The Sub-elements of a <servlet>

Sub-element

Description

<servlet-name>

The <servlet-name> element is simply the canonical name of the deployed servlet.

<servlet-class>

The <servlet-class> sub-element references the fully qualified class name of the servlet.

<init-param>

The <init-parameter> sub-element is an optional parameter containing a name-value pair that is passed to the servlet on initialization. It contains two sub-elements, <param-name> and <param-value>, which contain the name and value, respectively, to be passed to the servlet.

<load-on-startup>

The <load-on-startup> sub-element indicates the order in which each servlet should be loaded. Lower positive values are loaded first. If the value is negative or unspecified, then the container can load the servlet at anytime during startup.



Demystifying Tomcat 4's server.xml File

The Tomcat server.xml file allows you to configure Tomcat using a simple XML descriptor. This XML file is at the heart of Tomcat. In this article, I will focus on the configuration of all of the major Tomcat components found in the server.xml file. To examine these components, open your server.xml file, which can be found in the conf/ directory of your Tomcat installation. The following listing contains a simplified version of the default server.xml file.

Note: We will be focusing on the server.xml file as it is configured for Tomcat 4.0.4.

A simple server.xml file

<Server port="8005" shutdown="SHUTDOWN" debug="0">
  <Service name="Tomcat-Standalone">
    <Connector className="org.apache.catalina.connector.http.HttpConnector"
      port="8080" minProcessors="5" maxProcessors="75"
      enableLookups="true" redirectPort="8443"
      acceptCount="10" debug="0" connectionTimeout="60000"/>
    <Engine name="Standalone" defaultHost="localhost" debug="0">
      <Logger className="org.apache.catalina.logger.FileLogger"
        prefix="catalina_log." suffix=".txt"
        timestamp="true"/>
      <Realm className="org.apache.catalina.realm.MemoryRealm" />
      <Host name="localhost" debug="0" appBase="webapps" unpackWARs="true">
        <Valve className="org.apache.catalina.valves.AccessLogValve"
          directory="logs" prefix="localhost_access_log." suffix=".txt"
          pattern="common"/>
        <Logger className="org.apache.catalina.logger.FileLogger"
         directory="logs" prefix="localhost_log." suffix=".txt"
         timestamp="true"/>
        <Context path="/examples" docBase="examples" debug="0"
         reloadable="true">
          <Logger className="org.apache.catalina.logger.FileLogger"
          prefix="localhost_examples_log." suffix=".txt"
          timestamp="true"/>
         </Context>
      </Host>
    </Engine>
  </Service>
</Server>

The <Server> Element

The first element found in the server.xml file is the <Server> element. This element represents the entire Tomcat container. It is used as a top-level element for a single Tomcat instance.

The <Server> element is defined by the org.apache.catalina.Server interface. The Server interface is a simple singleton element that represents the entire Tomcat JVM. Each <Server> may contain one or more Service instances. The following list defines the possible attributes that can be set for the <Server> element.

className: Names the fully-qualified Java class name of the class that implements the org.apache.cataline.Server interface. If no class name is specified, the implementation will be used, which is the org.apache.catalina.core.StandardServer.

port: Names the TCP/IP port number to which the server listens for a shutdown command. The TCP/IP client that issues the shutdown command must be running on the same computer that is running Tomcat. This attribute is required.

shutdown: Defines the command string to shut down Tomcat. It must be received by the server on the named port. This attribute is required.

The <Server> element defined in the default server.xml file is contained in the following code snippet:

<Server port="8005"
  shutdown="SHUTDOWN"
  debug="0">

Note: The debug attribute is available to all Tomcat elements. It states the debug level to use when logging messages to a defined Logger. We will look at a Logger definition later in this article.

The <Server> element cannot be configured as a child of any elements. It can be configured as a parent to the <Service> element.

The <Service> Element

The next element in the server.xml file is the <Service> element, which acts as a container for one or more <Connector> elements that share a single <Engine> element. One or more <Service> elements may be nested inside of a single <Server> element. The <Service> element is defined by the org.apache.catalina.Service interface. The following list describes the possible <Service> element attributes.

className: Names the fully-qualified Java class name of the class that implements the org.apache.cataline.Service interface. If no class name is specified, the implementation will be used, which is the org.apache.catalina.core.StandardService.

shutdown: Defines the command string to shut down Tomcat. It must be received by the server on the named port. This attribute is required.

The <Service> element found in our server.xml file describes a service that represents a stand-alone Tomcat service that will handle all direct requests received by Tomcat.

<Service name="Tomcat-Standalone">

Note: I will discuss how to add additional <Service> elements in a subsequent article.

The <Service> element can be configured as a child of the <Server> element. It can be configured as a parent to the <Connector> and <Engine> elements.

The <Engine> Element

The third element in the server.xml file is the <Engine> element, which represents the Catalina servlet container. There can only be one <Engine> element for each defined <Service>. This single <Engine> component will receive all requests received by all of the defined <Connector> components. The <Engine> element must be nested immediately after the <Connector> elements, inside of its owning <Service> element.

The <Engine> element is defined by the org.apache.catalina.Engine interface. The following list describes the possible <Engine> element attributes.

className: Names the fully-qualified Java class name of the class that implements the org.apache.cataline.Engine interface. If no class name is specified, the implementation will be used, which is the org.apache.catalina.core.StandardEngine.

defaultHost: Names the host name to which all requests will be defaulted if not otherwise named. The named host must be defined by a child <Host> element.

name: Defines the logical name of this engine. The name selected is arbitrary, but it is required.

The following code snippet contains the <Engine> element defined in the server.xml file. The element defines an engine named Standalone with a default host of localhost.

<Engine name="Standalone" defaultHost="localhost" debug="0">

The <Engine> element can be configured as a child of the <Service> element. It can be configured as a parent to the following elements:

  • <Logger>
  • <Realm>
  • <Valve>
  • <Host>

The <Host> Element

The <Host> element defines the virtual hosts that are contained in each instance of a Catalina <Engine>. Each <Host> can be a parent to one or more Web applications, which are represented by a <Context> component, which will be described in the following section.

You must define at least one <Host> for each Engine element. The possible attributes for the <Host> element are described below.

className: Names the fully-qualified Java class name of the class that implements the org.apache.catalina.Host interface. If no class name is specified, the implementation will be used, which is the org.apache.catalina.core.StandardHost.

appBase: Defines the directory for this virtual host. This directory is the pathname of the Web applications to be executed in this virtual host. This value can be an absolute path, or a path that is relative to the <CATALINA_HOME> directory. If this value is not specified, the relative value webapps will be used.

unpackWARs: Determines if WAR files should be unpacked, or run directly from the WAR file. If not specified, the default value is true.

name: Defines host name of this virtual host. This attribute is required, and must be unique among the virtual hosts running in this servlet container.

The <Host> element defined for the Standalone <Engine> is listed in the following code snippet:

<Host name="localhost" debug="0" appBase="webapps" unpackWARs="true">

The host definition defines a host named localhost that can be accessed by opening the URL http://localhost:8080/.

Note: The port 8080 appended to the previous URL is defined by the <Connector> element, which will be described later in this article.

The <Host> element is configured as a child of the <Engine> element. It can be configured as a parent to the following elements:

  • <Logger>
  • <Realm>
  • <Valve>
  • <Context>

The <Context> Element

The <Context> element is the most commonly used element in the server.xml file. It represents an individual Web application that is running within a defined <Host>. There is no limit to the number of contexts that can be defined within a <Host> element. Each <Context> definition must have a unique context path, which is defined by the path attribute. The possible attributes for the <Context> element are described below.

className: Names the fully-qualified Java class name of the class that implements the org.apache.catalina.Host interface. If no class name is specified, the implementation will be used, which is the org.apache.catalina.core.StandardContext.

cookies: Determines if you want cookies to be used for session identifier. The default value is true.

crossContext: When set to true, allows the ServletContext.getContext() method to successfully return the ServletContext for other Web applications running in the same host. The default value is false, which will prevent the access of cross-context access.

docBase: Defines the directory for the Web application associated with this <Context>. This is the pathname of a directory that contains the resources for the Web application.

path: Defines the context path for this Web application. This value must be unique for each <Context> defined in a given <Host>.

reloadable: If set to true, causes Tomcat to check for class changes in the WEB-INF/classes/ and WEB-INF/lib directories. If these classes have changed, the application owning these classes will automatically be reloaded. This feature should only be used during development. This setting will cause severe performance degradation, and therefore should be set to false when in a production environment.

wrapperClass: Defines the Java class name of the org.apache.catalina.Wrapper implementation class that will be used to wrap servlets managed by this Context. If not specified, the standard value org.apache.catalina.core.StandardWrapper will be used.

useNaming: Set this value to true if you want Catalina to enable JNDI. The default value is true.

override: Set this value to to override the DefaultContext configuration.The default value is false.

workDir: Defines the pathname to a scratch directory that will be used by this <Context> for temporary read and write access. The directory will be made visible as a servlet context attribute of type java.io.File, with the standard key of java.servlet.context.tempdir. If this value is not specified, Tomcat will use the work directory.

The <Context> element that defines the /examples application is included in the following code snippet:

<Context path="/examples" docBase="examples" debug="0"
reloadable="true">

The context definition defines a Web application named /examples that will have all of its resources stored in the directory <TOMCAT_HOME>/Webapps/examples. This context also states that this application will be reloaded when class files are changed.

The <Context> element is configured as a child of the <Host> element. It can be configured as a parent to the following elements:

  • <Logger>
  • <Loader>
  • <Realm>
  • <Manager>
  • <Ejb>
  • <Environment>
  • <Parameter>
  • <Resource>
  • <ResourceParams>

Note: If you do not have special configuration needs, you can use the default context configuration that is described in the default web.xml file, which can be found in the <CATALINA_HOME>/conf/ directory.

The <Connector> Element

The final element we are going to examine is the <Connector> element. The <Connector> element defines the component that does the actual managing of requests and responses to and from a calling client. The <Connector> element is defined by the org.apache.catalina.Connector interface. The <Connector> element's attributes are described below.

className: Names the fully-qualified Java class name of the class that implements the org.apache.catalina.Host interface. If no class name is specified, the implementation will be used, which is the org.apache.catalina.Connector interface.

enableLookups: Determines whether DNS lookups are enabled. The default value for this attribute is true. When DNS lookups are enabled, an application calling request.getRemoteHost() will be returned the domain name of the calling client. Enabling DNS lookups can have an unfavorable impact on performance, so this value should most often be set to false.

redirectPort: Names the TCP/IP port number to which a request should be redirected, if it comes in on a non-SSL port, and is subject to a security constraint with a transport guarantee that requires SSL.

name: Defines host name of this virtual host. This attribute is required, and must be unique among the virtual hosts running in this servlet container.

The <Connector> element is configured as a child of the <Service> element. It cannot be configured as a parent to any element.

The HTTP Connector

The most common Tomcat connector is the HTTP connector, which is preconfigured with Tomcat. Like all connectors, the HTTP connector implements the org.apache.catalina.Connector interface, which automatically associates it with the connector attributes described above, but it also defines a set of attributes that are specific to the HttpConnector. These additional attributes are listed here.

port: Names the TCP/IP port number on which the connector listens for requests. The default value is 8080. If you want Tomcat to process requests using the default HTTP port of 80, simply set this attribute to 80.

address: This attribute is used for servers with more than one IP address. It specifies which address will be used for listening on the specified port. If this attribute is not specified, this named port number will be used on all IP addresses associated with this server.

bufferSize: Specifies the size, in bytes, of the buffer to be provided for use by input streams created by this connector. Increasing the buffer size can improve performance, at the expense of higher memory usage. The default value is 2048 bytes.

className: Names the fully-qualified Java class name of the HTTP connector class. This value must equal org.apache.cataline.connector.http.HttpConnector.

enableLookups: Same for all connectors.

proxyName: Specifies the server name to use if this instance of Tomcat is behind a firewall. This is an optional attribute.

proxyPort: Specifies the HTTP port to use if this instance of Tomcat is behind a firewall. An optional attribute.

minProcessors: Defines the minimum number of processors, or instances, to start at initialization time. The default value is 5.

maxProcessors: Defines the maximum number of allowed processors, or instances, that can be started. The default value is 20. An unlimited number of processors can be started if the value of the maxProcessors attribute is set to a number less than zero.

acceptCount: Specifies the number of requests that can be queued on the listening port. The default value is 10.

connectionTimeout: Defines time, in milliseconds, before a request terminates. The default value is 60000 milliseconds. To disable connection timeouts, the connectionTimeout value should be set to -1.

An example <Connector> defining a HTTP connector is contained in the following code snippet:

<Connector className="org.apache.catalina.connector.http.HttpConnector"
  port="8080"
  minProcessors="5"
  maxProcessors="75"
  enableLookups="true"
  redirectPort="8443"
  acceptCount="10"
  debug="0"
  connectionTimeout="60000"/>

This <Connector> defines an HttpConnector that listens for requests on port 8080. It starts with a minimum of five processors and can start up to as many as 75 processors.


: