当前位置 : 首页 » 文章分类 :  开发  »  Apache-Tomcat

Apache-Tomcat

Tomcat 使用笔记

http://tomcat.apache.org/


安装

下载版本选择

做JavaEE开发的朋友,无论是学习者还是已经工作的朋友,总是会用到Tomcat这个Servlet容器,那么大家从Tomcat官网上去下载tomcat的时候总会看到下载列表中有如下内容(下面以下载6.0.43版为例):
Binary Distributions

  • Core:
  • zip (pgp, md5)
  • tar.gz (pgp, md5)
  • 32-bit Windows zip (pgp, md5)
  • 64-bit Windows zip (pgp, md5)
  • 64-bit Itanium Windows zip (pgp, md5)
  • 32-bit/64-bit Windows Service Installer (pgp, md5)
  • Deployer:
  • zip (pgp, md5)
  • tar.gz (pgp, md5)

Source Code Distributions

  • tar.gz (pgp, md5)
  • zip (pgp, md5)

看到这里大家知道同一个版本的Tomcat有不同的下载版本,Binary Distributions和Source Code Distributions大家应该能分清楚,分别是二进制版本和源代码本。困惑在于Binary Distributions下面又有Core和Deployer两个,这两个有什么区别?我们到底应该选择哪个呢?
先说这两者的区别。
Core:是Tomcat正式的二进制发布版本,一般大家做开发或者学习的时候应该下载Core下的。具体的,在linux下用,下载zip或tar.gz版本;在windows下用,下载win 32或64 zip版,或Windows Service Installer版,zip为绿色版,免安装,解压后即用,Installer版是exe安装程序,需安装后使用。
Deployer:是基于Tomcat的web应用的发布器,就是在把写好的JavaEE应用发布到Tomcat的时候可以使用Deployer来动态的发布。所以它不是真正的Tomcat二进制版本,它只是一个用以发布基于Tomcat的Web应用的发布工具而已。因此,大家在下载的时候不应该下载这个东西,除非想动态的发布Web应用到Tomcat中去。


version.sh 查看tomcat版本

Tomcat 本身提供了查看版本的脚本命令:version
在 Tomcat 的安装目录的 bin 子目录下,有两个文件:
version.bat – Windows下的批处理脚本
version.sh – Linux下的Shell脚本

# ./version.sh
Using CATALINA_BASE:   /home/aicu-tob/software/tomcat-bscc-proxy-8888
Using CATALINA_HOME:   /home/aicu-tob/software/tomcat-bscc-proxy-8888
Using CATALINA_TMPDIR: /home/aicu-tob/software/tomcat-bscc-proxy-8888/temp
Using JRE_HOME:        /home/aicu-tob/software/jdk1.8.0_131
Using CLASSPATH:       /home/aicu-tob/software/tomcat-bscc-proxy-8888/bin/bootstrap.jar:/home/aicu-tob/software/tomcat-bscc-proxy-8888/bin/tomcat-juli.jar
Server version: Apache Tomcat/9.0.0.M6
Server built:   May 11 2016 21:43:59 UTC
Server number:  9.0.0.0
OS Name:        Linux
OS Version:     3.10.0-327.el7.x86_64
Architecture:   amd64
JVM Version:    1.8.0_131-b11
JVM Vendor:     Oracle Corporation

Mac 安装 Tomcat

http://tomcat.apache.org/ 下载 Binary Distributions -> Core -> zip 版最新 Tomcat apache-tomcat-9.0.16.zip
将解压后的文件夹 apache-tomcat-9.0.16 拖到 ~/Library/ 目录(即 用户名/资源库 目录),执行 bin/startup.sh 启动Tomcat
若脚本没有执行权限需要先添加可执行权限
chmod a+x startup.sh
chmod a+x catalina.sh
打开 http://localhost:8080 能看到 Tomcat 欢迎页面即安装启动成功。


Mac Brew 安装 tomcat

查看可用的 tomcat 安装包
brew search tomcat

安装 tomcat
brew install tomcat
安装 tomcat@9
brew install tomcat@9

Intel Mac 安装目录:
/usr/local/Cellar/tomcat/9.0.37/libexec
/usr/local/Cellar/tomcat/10.0.6/libexec

M1 Mac 安装目录:
/opt/homebrew/Cellar/tomcat/10.0.17

看安装是否成功:

catalina -h
Using CATALINA_BASE:   /usr/local/Cellar/tomcat/9.0.37/libexec
Using CATALINA_HOME:   /usr/local/Cellar/tomcat/9.0.37/libexec
Using CATALINA_TMPDIR: /usr/local/Cellar/tomcat/9.0.37/libexec/temp
Using JRE_HOME:        /usr/local/opt/openjdk
Using CLASSPATH:       /usr/local/Cellar/tomcat/9.0.37/libexec/bin/bootstrap.jar:/usr/local/Cellar/tomcat/9.0.37/libexec/bin/tomcat-juli.jar
Usage: catalina.sh ( commands ... )
commands:
  debug             Start Catalina in a debugger
  debug -security   Debug Catalina with a security manager
  jpda start        Start Catalina under JPDA debugger
  run               Start Catalina in the current window
  run -security     Start in the current window with security manager
  start             Start Catalina in a separate window
  start -security   Start in a separate window with security manager
  stop              Stop Catalina, waiting up to 5 seconds for the process to end
  stop n            Stop Catalina, waiting up to n seconds for the process to end
  stop -force       Stop Catalina, wait up to 5 seconds and then use kill -KILL if still running
  stop n -force     Stop Catalina, wait up to n seconds and then use kill -KILL if still running
  configtest        Run a basic syntax check on server.xml - check exit code for result
  version           What version of tomcat are you running?
Note: Waiting for the process to end and use of the -force option require that $CATALINA_PID is defined

启动 tomcat
catalina run

http://localhost:8080/
能看到 tomcat 介绍页

webapp的根目录
/usr/local/Cellar/tomcat/9.0.37/libexec/webapps


启动关闭tomcat

启动tomcat

在windows下可以通过两种方式启动:

bin/startup.bat
bin/catalina.bat start

在linix系统下可以通过下面的方式启动:

bin/startup.sh
bin/catalina.sh start

startup.sh 和 catalina.sh

startup.sh 就是 catalina.sh start 后台启动 tomcat
catalina.sh run 前台启动 tomcat
catalina.sh start 后台启动 tomcat

启动后,通过 http://localhost:8080 可以访问tomcat本地首页。

查看tomcat版本号

1、tomcat 欢迎页面上看版本号
2、curl 主页,返回结果中有版本号
3、找到 tomcat 包下面的 /bin 目录,执行 version.sh 文件。对应的 Server number 即是tomcat所对应的版本信息

# ./version.sh
Using CATALINA_BASE:   /root/software/tomcat
Using CATALINA_HOME:   /root/software/tomcat
Using CATALINA_TMPDIR: /root/software/tomcat/temp
Using JRE_HOME:        /opt/jdk1.8.0_101/jre
Using CLASSPATH:       /root/software/tomcat/bin/bootstrap.jar:/root/software/tomcat/bin/tomcat-juli.jar
Using CATALINA_OPTS:
Picked up JAVA_TOOL_OPTIONS: -javaagent:/root/data/skywalking/skywalking-agent.jar
...
Server version: Apache Tomcat/9.0.50
Server built:   Jun 28 2021 08:46:44 UTC
Server number:  9.0.50.0
OS Name:        Linux
OS Version:     4.17.11-1.el7.elrepo.x86_64
Architecture:   amd64
JVM Version:    1.8.0_101-b13
JVM Vendor:     Oracle Corporation

关闭tomcat

在windows下可以通过下面方式关闭:

bin/shutdown.bat
bin/catalina.bat stop

或者直接关闭启动窗口

在linix下可以通过下面的方式关闭:

bin/shutdown.sh
bin/catalina.sh stop

或者直接在终端中停止脚本


tomcat目录结构

  • bin:包含启动、关闭tomcat和其他一些脚本。.sh文件是UNIX系统用的,.bat是window系统用的,但功能是相同的。因为WIN32系统缺乏某些功能,因此在该目录下还包含一些辅助文件。
  • lib:tomcat核心类库,即依赖的jar包
  • conf:包含一些配置文件和DTD文件,最重要的文件是server.xml,它是tomcat的主配置文件。
  • logs:日志目录,存放日志文件。
  • webapps:应用目录,web应用部署在这里。
  • work:JVM临时文件目录[java.io.tmpdir]
  • temp:临时文件目录

Tomcat配置

catalina.home和catalina.base

catalina.home(安装目录):指向公用信息的位置,就是bin和lib的父目录。
catalina.base(工作目录):指向每个Tomcat目录私有信息的位置,就是conf、logs、temp、webapps和work的父目录。
仅运行一个Tomcat实例时,这两个属性指向的位置是相同的。

tomcat配置文件

conf 目录中的配置文件:

  • server.xml:主配置文件;
  • context.xml:每个webapp都可以有专用的配置文件,这些配置文件通常位于webapp程序目录下的WEB-INF目录中,用于定义会话管理顺、JDBC等;conf/context.xml是为各webapp提供默认配置;
  • web.xml:每个webapp只有在“部署”之后才能够被访问;此文件则用于为各webapps定义默认的部署操作方式;
  • tomcat-users.xml:用户认证的账号和密码配置文件;
  • catalina.policy:当使用-security选项来启动tomcat实例时会读取此配置文件来实现基于安全策略的运行方式;
  • catalina.properties:Java属性的定义文件,用于设定类加载器路径等 ,以及一些与JVM性能相关的调优参数;
  • logging.properties:日志系统相关的配置;

Tomcat基础
http://www.cnblogs.com/carl10086/p/5998706.html

【Tomcat 6.0官方文档翻译】—— 简介
http://www.cnblogs.com/xing901022/p/4412469.html


server.xml

tomcat9 server.xml 配置文档
Apache Tomcat 9 Configuration Reference
https://tomcat.apache.org/tomcat-9.0-doc/config/http.html

server.xml不能热更新

server.xml 是不可动态重加载的资源,服务器一旦启动了以后,要修改这个文件,就得重启服务器才能重新加载。

Server

<Server port="8005" shutdown="SHUTDOWN">
这会让 Tomcat 启动一个 server 实例(即一个JVM),它监听在 8005 端口以接收 SHUTDOWN 命令。各 Server 的定义不能使用同一个端口,这意味着如果在同一个物理机上启动了多个 Server 实例,必须配置它们使用不同的端口。这个端口的定义用于为管理员提供一个关闭此实例的便捷途径,因此,管理员可以直接 telnet 至此端口使用 SHUTDOWN 命令关闭此实例。不过,基于安全角度的考虑,这通常不允许远程进行。

Server的相关属性:
className: 用于实现此 Server 容器的完全限定类的名称,默认为 org.apache.catalina.core.StandardServer
port: 接收 shutdown 指令的端口,默认仅允许通过本机访问,默认为 8005
shutdown: 发往此 Server 用于实现关闭 tomcat 实例的命令字符串,默认为 SHUTDOWN

Service

<Service name="Catalina">
Service 主要用于关联一个引擎和与此引擎相关的连接器,每个连接器通过一个特定的端口和协议接收入站请求并将其转发至关联的引擎进行处理。困此,Service 要包含一个引擎、一个或多个连接器。
这定义了一个名为 Catalina 的 Service, 此名字也会在产生相关的日志信息时记录在日志文件当中。

Service 相关的属性:
className: 用于实现 service 的类名,一般都是 org.apache.catalina.core.StandardService
name: 此服务的名称,默认为 Catalina


HTTP/1.1 Connector

Connector 的主要功能,是接收连接请求,创建 Request 和 Response 对象用于和请求端交换数据;然后分配线程让 Engine 来处理这个请求,并把产生的 Request 和 Response 对象传给 Engine.

例如

<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" />

表示客户端可以通过 8080 端口号使用 http 协议访问 Tomcat, 其中,protocol 属性规定了请求的协议,port 规定了请求的端口号,redirectPort 表示当强制要求 https 而请求是 http 时,重定向至端口号为 8443 的 Connector, connectionTimeout 表示连接的超时时间。

Tomcat请求处理过程

Tomcat处理请求的过程:在accept队列中接收连接(当客户端向服务器发送请求时,如果客户端与OS完成三次握手建立了连接,则OS将该连接放入accept队列);在连接中获取请求的数据,生成request;调用servlet容器处理请求;返回response。

Connector与protocol

Connector在处理HTTP请求时,会使用不同的protocol。不同的Tomcat版本支持的protocol不同,其中最典型的protocol包括BIO、NIO和APR(Tomcat7中支持这3种,Tomcat8增加了对NIO2的支持,而到了Tomcat8.5和Tomcat9.0,则去掉了对BIO的支持)。

BIO是Blocking IO,顾名思义是阻塞的IO;NIO是Non-blocking IO,则是非阻塞的IO。而APR是Apache Portable Runtime,是Apache可移植运行库,利用本地库可以实现高可扩展性、高性能;Apr是在Tomcat上运行高并发应用的首选模式,但是需要安装apr、apr-utils、tomcat-native等包。

protocol(默认HTTP/1.1)

设置为 HTTP/1.1 或者不设置 protocol 使用默认值时,含义如下:在Tomcat7中,自动选取使用BIO或APR(如果找到APR需要的本地库,则使用APR,否则使用BIO);在Tomcat8及以上版本中,自动选取使用NIO或APR(如果找到APR需要的本地库,则使用APR,否则使用NIO)。

或者也可以显式指定使用的协议
org.apache.coyote.http11.Http11Protocol BIO,Tomcat 9之后不再支持
org.apache.coyote.http11.Http11NioProtocol NIO
org.apache.coyote.http11.Http11Nio2Protocol NIO2
org.apache.coyote.http11.Http11AprProtocol APR

maxThreads(默认200)

connector 创建的请求处理线程的最大数量。
如果该Connector绑定了Executor,这个值会被忽略,因为该Connector将使用绑定的Executor,而不是内置的线程池来执行任务。
最大线程数决定了Web服务可以同时处理多少个请求
经验值范围为200-800,可以从400设置起再进行调优
当cpu利用率高的时候,不宜增加线程的个数,可以调小该值
当cpu利用率不高,大部分是io阻塞类的操作时,可以适当增加该值

maxConnections(NIO默认10000)

Tomcat在任意时刻接收和处理的最大连接数。当Tomcat接收的连接数达到maxConnections时,Acceptor线程不会读取accept队列中的连接;这时accept队列中的线程会一直阻塞着,直到Tomcat接收的连接数小于maxConnections。如果设置为-1,则连接数不受限制。

这个参数是指在同一时间,tomcat能够接受的最大连接数。一般这个值要大于 maxThreads+acceptCount

tomcat的最大连接数参数是maxConnections,这个值表示最多可以有多少个socket连接到tomcat上。

默认值与连接器使用的协议有关:BIO模式下默认最大连接数是它的最大线程数(缺省是200),NIO模式下默认是10000,APR模式则是8192(windows上则是低于或等于maxConnections的1024的倍数)。如果设置为-1则表示不限制

maxConnections的设置与Tomcat的运行模式有关。如果tomcat使用的是BIO,那么maxConnections的值应该与maxThreads一致;如果tomcat使用的是NIO,maxConnections值应该远大于maxThreads

acceptCount(默认100)

当所有请求处理线程都占满时,Tomcat会用队列缓存进入的请求,这个 acceptCount 值就是队列的最大长度。当队列也满了的时候,后续请求将被拒绝(connection refused)。
默认值是100

acceptCount的经验值的范围为50-300,当tomcat的处理能力不够快的时候,可以调整该值,比较有用。

当acceptCount的值设置的太小的时候,当请求量大的时候,操作系统无法给tomcat建立更多的连接(无法完成三次握手),client端出现很多connect refused,而这些被拒绝掉的请求可能是在worker线程的处理能力之内的。

connectionTimeout(默认60秒)

默认值是60秒,但是要注意随着Tomcat一起交付的标准 server.xml 中的配置都是20秒。

经验值为2000-60000,默认的60秒对于一个web server可能太高了,可以设置为3000
实际上指的是SO_TIMEOUT参数的值
代表在阻塞读写时,两个tcp包到来的最大间隔时间
当client比较慢的时候,可以增大该值
当需要快速超时时,可以降低该值

tomcat9 server.xml 配置文档
https://tomcat.apache.org/tomcat-9.0-doc/config/http.html

深度理解Tomcat的acceptCount、maxConnections、maxThreads(这篇从原理上讲的很透彻)
https://blog.csdn.net/zzzgd_666/article/details/88740198


Engine

Engine组件在Service组件中有且只有一个;Engine是Service组件中的请求处理组件。Engine组件从一个或多个Connector中接收请求并处理,并将完成的响应返回给Connector,最终传递给客户端。

Engine包含Host,Host包含Context

<Engine name="Catalina" defaultHost="localhost">

其中,name属性用于日志和错误信息,在整个Server中应该唯一。defaultHost属性指定了默认的host名称,当发往本机的请求指定的host名称不存在时,一律使用defaultHost指定的host进行处理;因此,defaultHost的值,必须与Engine中的一个Host组件的name属性值匹配。

Host

Host是Engine的子容器。Engine组件中可以内嵌1个或多个Host组件,每个Host组件代表Engine中的一个虚拟主机。Host组件至少有一个,且其中一个的name必须与Engine组件的defaultHost属性相匹配

Host虚拟主机的作用,是运行多个Web应用(一个Context代表一个Web应用),并负责安装、展开、启动和结束每个Web应用。

Host组件代表的虚拟主机,对应了服务器中一个网络名实体(如”www.test.com”,或IP地址”116.25.25.25”);为了使用户可以通过网络名连接Tomcat服务器,这个名字应该在DNS服务器上注册。

客户端通常使用主机名来标识它们希望连接的服务器;该主机名也会包含在HTTP请求头中。Tomcat从HTTP头中提取出主机名,寻找名称匹配的主机。如果没有匹配,请求将发送至默认主机。因此默认主机不需要是在DNS服务器中注册的网络名,因为任何与所有Host名称不匹配的请求,都会路由至默认主机。

<Host name="localhost"  appBase="webapps" unpackWARs="true" autoDeploy="true">
</Host>

name属性指定虚拟主机的主机名,一个Engine中有且仅有一个Host组件的name属性与Engine组件的defaultHost属性相匹配;一般情况下,主机名需要是在DNS服务器中注册的网络名,但是Engine指定的defaultHost不需要,原因在前面已经说明。

unpackWARs指定了是否将代表Web应用的WAR文件解压;如果为true,通过解压后的文件结构运行该Web应用,如果为false,直接使用WAR文件运行Web应用。

Context

Context元素代表在特定虚拟主机上运行的一个Web应用。每个Web应用基于WAR文件,或WAR文件解压后对应的目录(这里称为应用目录)。

Context是Host的子容器,每个Host中可以定义任意多的Context元素。

有的 server.xml 配置文件中并没有出现Context元素的配置。这是因为,Tomcat开启了自动部署,Web应用没有在server.xml中配置静态部署,而是由Tomcat通过特定的规则自动部署。

<Context path="" sessionCookieName="My-API-EXPORT-JSESSIONID" docBase="/root/apps/app-rest" debug="0" />

详解Tomcat 配置文件server.xml
https://www.cnblogs.com/kismetv/p/7228274.html


AJP Connector

The AJP Connector is configured with secretRequired=”true”

java.lang.IllegalArgumentException: The AJP Connector is configured with secretRequired=”true” but the secret attribute is either null or “”. This combination is not valid.
AJP 连接器配置 secretRequired=”true”, 但是属性 secret 确实空或者空字符串,这样的组合是无效的。

根据错误提示,需要添加 secretRequired 和 secret 属性,如果 设置 secretRequired=”” 则可以不用添加 secret 属性,配置正确之后即可正常启动。

编辑 Tomcat server.xml 配置
/usr/local/Cellar/tomcat/9.0.37/libexec/conf/server.xml

<Connector protocol="AJP/1.3"
           address="::1"
           port="8009"
           redirectPort="8443"
           secretRequired="" />

IDEA配置本地tomcat启动项目

idea专业版

1、以 Tomcat Server -> Local 为模板创建 run/debug 配置

2、Deployment 标签页中,Deploy at the server startup 中点加号,增加 Artifact
(1)这里能自动列出 artifact 的前提是 idea 能识别出这个 artifact,比如社区版就没有这个功能
(2)假如项目里有一个 war 模块 my-app, 这里会显示两个 artifact,my-app:warmy-app:war exploded,选择 my-app:war exploded, 这个就是打包后的 my-app war 包的解压版,这里是从 pom 中读取的 artifactId, 不是 build 的 finalName。
(3)下面的 Application Context 默认是根据选择的 artifact 来决定的,比如是 my-app, 这样的话启动的api中都带有路径 /my-app 如果不想这样,把这里的上下文改为 /。

3、Server 标签页中
(1)首先本地安装 Tomcat, Mac 的话直接 brew 安装即可。
(2)首次配置时,Application server 中是空的,需要指定 Tomcat 安装目录。然后点右侧的 Configure… 弹出对话框中选择 Tomcat Home 目录 /usr/local/Cellar/tomcat/10.0.6/libexec 点确定后 Application server 中可以看到对应版本的 Tomcat
(3)Tomcat Server Settings 中的 HTTP port 配置为想要的端口, 其他都默认。
(4)此外,还可以配置 Open Browser, 默认勾选了 After Launch, 填入 local swagger 地址可实现启动后自动打开 swagger 页面。

war和war exploded的区别

是选择war还是war exploded 这里首先看一下他们两个的区别
war模式:将WEB工程以包的形式上传到服务器 ;
war exploded模式:将WEB工程以当前文件夹的位置关系上传到服务器;

(1)war模式这种可以称之为是发布模式,看名字也知道,这是先打成war包,再发布;
(2)war exploded模式是直接把文件夹、jsp页面 、classes等等移到Tomcat 部署文件夹里面,进行加载部署。因此这种方式支持热部署,一般在开发的时候也是用这种方式。
(3)在平时开发的时候,使用热部署的话,应该对Tomcat进行相应的设置,这样的话修改的jsp界面什么的东西才可以及时的显示出来。

idea社区版通过Smart Tomcat插件配置

注:这种方式比 idea 专业版的 Tomcat 模板启动慢的多,而且很耗资源,每次启动等半天不说,风扇狂转,有条件的话还是推荐使用专业版IDEA。

1、idea 插件库中搜索安装 Smart Tomcat
2、Run/Debug Configuration 中以 Smart Tomcat 为模板创建配置

Name:配置的名字,随便起。一般就用项目名
Tomcat Server:tomcat的路径。如果之前配置过,直接下拉选择就行。如果第一次配置,点右边的 Configuration, 点加号选择本机安装的 tomcat 的 libexec 路径,比如 brew 安装的 /usr/local/Cellar/tomcat/9.0.37/libexec, 选择后会自动识别出tomcat版本号(新窗口配置的Tomcat Server是idea系统级配置)。确定后在 Tomcat Server 中下来列表中就有了。
Deployment:项目的webapp所在的路径
Contex Path:上下文路径。会自己识别出来,一般我们不改这个。填了上下文路径后,启动后的项目地址就是 localhost:port/contexPath 了
Server Port:默认是8080,可以改成其它
VM options: 可选的。没有参数就不填


Tomcat Server配置

部署

web应用的标准目录结构

  • *.html, *.jsp, etc.:放置 HTML and JSP 网页以及css样式、图片等资料,大的项目可以再建立子目录。
  • /WEB-INF/web.xml:web应用的部署文件,是个XML文件。在这个文件你可以你可以定义servlet和一些组件,还能够初始化参数,以及安全上的一些限制设置。
  • /WEB-INF/classes/:在这个目录,放置java类文件,这些类文件是没有打包(JAR包)的类文件(servlet或非servlet类文件),放在这里的类必须和你的package目录结构一致。如类com.mycompany.mypackage.MyServlet ,目录就像下面/WEB-INF/classes/com/mycompany/mypackage/MyServlet.class
  • /WEB-INF/lib/:在这个目录,放置java类文件(用JAR形式),比如第三方的类库和数据库连接用的JDBC驱动类库。

当你将一个应用程序安装到tomcat,WEB-INF/classes/ 和 WEB-INF/lib/ 的类文件对于你特定的web应用程序里的其他类是可见的。 如果你将你所需要的所有类库放在这些位置,这将简化你的web应用程序的安装过程,而不必调整系统的类路径。(否则系统的类路径需要修改,不然import的类会找不到)

tomcat共享库

共享文件库放在$CATALINA_HOME/lib目录中,共所有web 应用程序共享。JAR文件放在这里对web应用程序和tomcat内部代码都是可见的。web应用程序或tomcat用到的JDBC drivers放在这里是比较合理的。
tomcat预安装的共享类库包括Servlet 3.0 and JSP 2.1 APIs 和XML Parser APIs(一个XML解析器,符合JAXP(Java API for XML Parsing:用于分析XML的API)),这样你就可以在你的应用程序中用基于DOM-based 或 SAX-based方式处理XML文件。(DOM文档对象模型,SAX The Simple API for XML,一个循序存取XML的API)

在tomcat中部署应用

$CATALINA_BASE 代表应用的基目录,相关的目录以它为根。如果你没有配置运行tomcat的多个实例,CATALINA_BASE将被设置为CATALINA_HOME。
几种在tomcat中部署应用的方法:

  • Copy unpacked directory hierarchy into a subdirectory in directory. 直接拷贝未打包的程序目录到 $CATALINA_BASE/webapps/,tomcat将分配一个 Context PATH 给你(根据你的应用的子目录名),在开发期间,这是最快最容易的方法。安装和更新web应用后必须重启tomcat。
  • Copy the web application archive file into directory $CATALINA_BASE/webapps/. 拷贝打包的web应用程序(war包)到 CATALINA_BASE/webapps/。如果拷贝时tomcat已经启动了,tomcat将自动解包,并且可执行。这种方式比较适合于从第三方来的打包的应用。注意:用这种方法部署,如果你想更新你的web应用,你必须删除tomcat自动解包的目录,并且将新的包覆盖原来的包。然后重启tomcat,反映你的变化。
  • Use the Tomcat “Manager” web application to deploy and undeploy web applications. 利用Tomcat “Manager” web application部署。tomcat默认有一个Manager的web应用程序,这个应用程序的Context PATH是/manager.允许你在一个运行tomcat的服务器上部署或卸载应用程序,而不需要重启。
  • Use “Manager” Ant Tasks In Your Build Script. 利用在Ant的部署文件中的“Manager”任务(task)。tomcat包含一组自定义的Ant任务,这些任务被用于tomcat的部署。
  • Use the Tomcat Deployer. tomcat包含一个绑定到ant tasks的打包工具,可以在部署到服务器之前自动对JSPs(也是web应用程序的其中一部分)预编译。

Tomcat应用发布
那么Deployer既然是用来发布Web应用到Tomcat中去的,那么它都能做些什么呢?
这里有必要跟大家交代一下Tomcat中的Web应用发布的概念。
发布:指的是把一个Web应用安装到Tomcat服务器中的过程。
在Tomcat中发布Web应用可以有两种方式:

  1. 静态发布:指的是在Tomcat未启动的时候,把做好的Web应用直接复制到Tomcat服务器中。
  2. 动态发布:有两种情况
  3. 指的是在Tomcat已经启动运行的情况下,通过Tomcat的自动部署功能动态操作已经发布的Web应用.
  4. 指的是通过Tomcat Manager这个Web应用通过远程把做好的Web应用发布到正在运行的Tomcat中去。

Deployer的作用就在动态发布Web应用到Tomcat中去的时候体现出来的。
Deployer是一个命令行的工具,它可以编译、验证Web应用,还可以把Web应用的全部资源打包到War文件中。

将应用部署到Tomcat根目录

将应用部署到Tomcat根目录的目的是可以通过“http://[ip]:[port]”直接访问应用,而不是使用“http://[ip]:[port]/[appName]”上下文路径进行访问。
方法一:(最简单直接的方法)
删除原 webapps/ROOT 目录下的所有文件,将应用下的所有文件和文件夹复制到ROOT文件夹下。

方法二:修改conf/server.xml配置
删除原 webapps/ROOT 目录下的所有文件,修改文件“conf/server.xml”,在Host节点下增加如下Context的内容配置:

<Host name="localhost"  appBase="webapps" unpackWARs="true" autoDeploy="true">
    ......
    <Context path="" docBase="C:/apache-tomcat-6.0.32/myapps/bc.war"></Context>
</Host>

注意:

  • path 的值设置为空;
  • 应用不要放到tomcat的webapps目录下(如上述配置是放到自定义的文件夹myapps内的),否则访问时路径很有问题;
  • docBase指定到绝对路径。

如此设置后重启tomcat,如果docBase指向的是war文件,会自动将war解压到 webapps/ROOT 目录;如果docBase指向的是应用已解压好的目录,如 docBase=”C:/apache-tomcat-6.0.32/myapps/bc”,tomcat不会生成webapps/ROOT目录(这种情况下之前可以不用删除webapps/ROOT目录,但webapps/ROOT目录内的内容是无法访问的),访问时将直接使用docBase指定的目录。

方法三:增加conf/Catalina/localhost/ROOT.xml配置
与方法二类似,但不是修改全局配置文件“conf/server.xml”,而是在“conf/Catalina/localhost”目录下增加新的文件”ROOT.xml”(注意大小写哦),文件内容如下:

<?xml version="1.0" encoding="UTF-8"?>
<Context path="" docBase="C:/apache-tomcat-6.0.32/myapps/bc.war"></Context>

Tomcat Maven Plugin

tomcat-maven-plugin

在pom.xm 加入以下配置:

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>tomcat-maven-plugin</artifactId>
    <version>1.1</version>
    <configuration>
        <path>/wp</path>
        <port>8080</port>
        <uriEncoding>UTF-8</uriEncoding>
        <url>http://localhost:8080/manager/html</url>
        <server>tomcat6</server>
    </configuration>
</plugin>

path 是访问应用的路径
port 是tomcat 的端口号
uriEncoding URL按UTF-8进行编码,这样就解决了中文参数乱码。
Server 指定tomcat名称。

启动tomcat插件
在Maven工程上右键->Run As->Maven build,在弹出的对话框中输入命令:
Goals:tomcat:run

常用Goal命令

  • tomcat:deploy,部署一个web war包
  • tomcat:reload,重新加载web war包
  • tomcat:start,启动tomcat
  • tomcat:stop,停止tomcat
  • tomcat:undeploy,停止一个war包
  • tomcat:run,启动嵌入式tomcat,并运行当前项目

tomcat7-maven-plugin

自从版本 2.0-beta-1 以后, tomcat mojos 更名为 tomcat6 和 tomcat7,POM配置如下:

<plugin>
  <groupId>org.apache.tomcat.maven</groupId>
  <artifactId>tomcat6-maven-plugin</artifactId>
  <version>2.3-SNAPSHOT</version>
</plugin>
<plugin>
  <groupId>org.apache.tomcat.maven</groupId>
  <artifactId>tomcat7-maven-plugin</artifactId>
  <version>2.3-SNAPSHOT</version>
</plugin>

使用方法基本一样:

<plugin>
    <groupId>org.apache.tomcat.maven</groupId>
    <artifactId>tomcat7-maven-plugin</artifactId>
    <version>2.1</version>
    <configuration>
        <port>9090</port>
        <path>/mgr</path>
        <uriEncoding>UTF-8</uriEncoding>
        <finalName>mgr</finalName>
        <server>tomcat7</server>
    </configuration>
</plugin>

Goal命令
如果使用tomcat7-maven-plugin,所有Goal命令都需要更改为:tomcat7:插件执行点,例如启动命令为:tomcat7:run

tomcat7:run-war
http://tomcat.apache.org/maven-plugin-2.1/tomcat7-maven-plugin/run-war-mojo.html

启动Tomcat的几种方式

启动Tomcat有两种场景,一是部署时启动,二是开发时启动。部署时基本上是通过war包来启动,而开发时的启动方式多种多样,下面拟介绍几种适用于开发时启动Tomcat的方法。
在DOS命令行启动
Apache Tomcat提供了一个名为tomcat7-maven-plugin的插件,该插件提供了多种启动Tomcat的方式。这里我们主要关心的是tomcat7:run 启动方式。
tomcat7:run所启动的是内置的Tomcat,与你本机是否安装了Tomcat无关。该内置的Tomcat会被Maven自动下载,并在执行tomcat7:run时被启动。我们可以在pom.xml里对这个内置Tomcat进行参数配置。使用内置Tomcat的好处是每次启动都是一个干净的环境,如果你长时间没关心某个工程,而突然要进行开发时,这个干净的环境很重要,让你立即还原到以前的工作环境中。
使用tomcat7:run时又有两个场景。如果你只有war工程,并且与其相关的jar文件都已上传到Maven服务器上了(或已安装到本地Maven库中),你可以在war工程的目录下执行下面的命令来启动:
mvn tomcat7:run
该命令将自动地把本地Maven库上的jar文件增加到classpath路径上,同时还会自动编译war工程,但并不打war包,启动较快。
另一个使用场景是,如果你有全部工程的源程序(若干jar工程和一个war工程),并且需要不时地修改程序,你可以在根工程下通过下面的命令来启动:
mvn tomcat7:run -am -pl abc
其中,假设abc是你的war工程名。该命令将自动地把各工程的源程序编译到各自的target/classes目录下,并添加到classpath路径中。同样,该命令也不打war包,减少了启动时间。
需要注意的是,上面的命令只处理根pom.xml里modules中定义的工程,其它所依赖的工程仍直接取本地Maven库中的jar文件。当然,我们也必须把那个war工程(即上面的abc)也定义到modules中才行。
在Eclipse里启动
在Eclipse里安装m2e和m2e-wtp插件后就可以在Servers中启动Tomcat了,这是我们首选的启动方式,此法不再赘述。
此外,我们还可以在Eclipse里执行上面说到的mvn tomcat7:run或mvn tomcat7:run -am -pl abc命令。在Eclipse里执行Maven命令比在DOS窗口里执行的一个好处是复制粘贴更容易,并且在程序抛异常后可以直接点击超链接打开对应的程序,并定位到出错的地方。


上一篇 JBoss-mod_cluster

下一篇 PostgreSQL-常用系统表及SQL

阅读
评论
8.1k
阅读预计33分钟
创建日期 2017-01-12
修改日期 2021-02-07
类别

页面信息

location:
protocol:
host:
hostname:
origin:
pathname:
href:
document:
referrer:
navigator:
platform:
userAgent:

评论