-------本文大纲
简介
Jsp环境部署
Tomcat目录结构
SHOP++网上商城系统安装
---------------
一、简介
JSP
JSP(Java Server Pages)是由Sun Microsystems公司倡导、许多公司参与一起建立的一种动态网页技术标准。在传统的网页HTML文件(*.htm,*.html)中插入Java程序段(Scriptlet)和JSP标记(tag),从而形成JSP文件(*.jsp)。简单地说,jsp就是可能包含了java程序段的html文件(由jasper将嵌入在html文档的程序整个的转换为serlet代码),为了和普通的html区别,因此使用jsp后缀名。
Servlet
Servlet是一种独立于平台和协议的服务器端的Java应用程序,可以生成动态的Web页面。 它担当Web浏览器或其他HTTP客户程序发出请求,与HTTP服务器上的数据库或应用程序之间的中间层。
Servlet是位于Web 服务器内部的服务器端的Java应用程序,与传统的从命令行启动的Java应用程序不同,Servlet由Web服务器进行加载,该Web服务器必须包含支持Servlet的Java虚拟机。
在通信量大的服务器上,Java servlet的优点在于它们的执行速度更快于CGI程序。各个用户请求被激活成单个程序中的一个线程,而创建单独的程序,这意味着各个请求的系统开销比较小。
简单地说,servlet就是在服务器端被执行的java程序,它可以处理用户的请求,并对这些请求做出响应。Servlet编程是纯粹的java编程,而jsp则是html和java编程的中庸形式,所有的jsp文件都将被最终转换成java servlet来执行。
从jsp到java到class,jsp在首次被请求时是要花费一定的服务器资源的。但庆幸的是,这种情况只发生一次,一旦这个jsp文件被翻译并编译成对应的servlet,在下次请求来临时,将直接由servlet来处理,除非这个jsp已经被修改。
JSP和Servlet的最大区别在于,Servlet通常需要事先编译好,而JSP则并非必须事先编译。这意味着Servlet通常放置于私有资源区域,而JSP则通常以嵌入代码的方式包含于HTML页面文件中,这些HTML文件通常放置在公开资源区域。
Tomcat
Tomcat是一个免费的开源的Serlvet容器,它是Apache基金会的Jakarta项目中的一个核心项目,由Apache,Sun和其它一些公司及个人共同开发而成。
Tomcat是稳固的独立的Web服务器与Servlet Container,不过,其Web服务器的功能则不如许多更健全的Web服务器完整,如Apache(Apache是一个强大的Web服务器 ,在处理静态页面、处理大量网络客户请求、支持服务的种类以及可配置方面都有优势,高速并且强壮,但是没有JSP/Servlet的解析能力)
将Apache和Tomcat整合起来可以看作是用Tomcat做Apache的jsp/servlet解析插件,不过Tomcat作为一个Web服务器,本身只具备了基本的Web服务功能。
二、Jsp环境部署
1、安装JDK(jdk-7u55-linux-x64)
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
安装后存放的路径
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
|
添加环境变量
1 2 3 4 5 6 7 8 |
|
到此,jdk安装完成。
2、安装Tomcat (apache-tomcat-7.0.53.tar.gz)
1 2 3 4 |
|
添加环境变量
1 2 3 4 5 6 |
|
启动服务
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
添加启动脚本
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
|
访问测试
到此,tomcat安装完成
3、Tomcat Manager
tomcat强大的管理工具,具有以下特性:
远程deploy新应用程序
清理空闲会话
在不重启container的情况下Undeploy应用程序
分析内存泄漏
JVM状态
服务器状态
然而,在tomcat7中,TM默认是禁用的。要启用之,需要编辑tomcat-users.xml文件;
只要简单的设置就可以
修改/usr/local/tomcat/conf/tomcat-users.xml
1 2 3 4 5 6 |
|
重启tomcat
1 2 3 4 5 6 7 8 9 10 11 12 |
|
web重新访问,在默认页面的右边有三个按钮
Server Status:服务器性能监控
Manager App :应用程序管理
输入登录密码
应用程序相关信息
应用程序部署
Context:
对于应用程序来说,context路径是一个关键属性,其也经常用于虚拟主机的配置及.war文件中的URL映射。使用context可以降低系统负载,因为,当某URL请求到达tomcat时,如果没有context,tomcat需要搜索server.xml或context.xml的配置以确定此URL,否则则需要搜索所有的war文件来查找用户的请求的资源。
此外,context也可以让管理员基于每个app提供日志、appBase、DB连接等配置,这极大地增强配置的灵活性;
Tomcat7 deploy应用程序的方法:
War格式的应用程序:将应用程序war文件放置于CATALINA_BASE目录中并重新启动tomcat;
没打包的应用程序:将应用程序的非归档文件复制于CATALINA_BASE目录中;
Tomcat Manager:登录TM而后进行deploy;
Deploy应用程序所涉及到的操作:
Deploy: 向tomcat实例提供某应用程序源文件,并让服务器将类加载进类加器中;这样,应用程序才可以为用户所使用;
Redeploy:用于更新deployment后的某应用程序或应用程序的部分内容;当redeploy整个应用程序时,当前应用程序的所有模块都必须要redeploy成功,否则整个webapp将会停止 ;
Stop: 卸载当前应用程序的所有类,并停止向用户提供服务;不过,其仍然会保留所有已deploy的文件及名称,并可用于后续的redeployment或starting;
Start: 重新装载当前应用的类至类加载器,并开启服务;
Undeploy: 停止某已经deploy的应用程序,并移除deploy产生的文件和名称;
Host Manager :布署虚拟主机
应用程序目录的结构:
/WEB-INF/web.xml:包含当前webapp的deploy描述符,如所有的servlets和JSP等动态文件的详细信息,会话超时时间和数据源等;因此,其也通常用于定义当前webapp特有的资源;
/WEB-INF/classes: 包含所有服务器端类及当前应用程序相关的其它第三方类等;
/WEB-INF/lib: 包含JSP所用到的JAR文件;
三、tomcat 目录结构
1 2 3 4 5 6 7 8 |
|
1、各目录的作用
bin ——Tomcat执行脚本目录
conf ——Tomcat配置文件
lib ——Tomcat运行需要的库文件(JARS)
logs ——Tomcat执行时的LOG文件
temp ——Tomcat临时文件存放目录
webapps ——Tomcat的主要Web发布目录(存放我们自JSP,SERVLET,CLASSES)
work ——Tomcat的工作目录,Tomcat将翻译JSP文件到的Java文件和class文件放在这
2、各目录中的文件
conf/
1 2 3 4 |
|
最主要的配置文件有
server.xml Tomcat 的全局配置文件
web.xml 为不同的Tomcat配置的web应用设置缺省值的文件
tomcat-users.xml Tomcat用户认证的配置文件
context.xml 用于虚拟主机的配置及.war文件中的URL映射。使用context可以降低系统负载,因为,当某URL请求到达tomcat时,如果没有context,tomcat需要搜索server.xml或context.xml的配置以确定此URL,否则则需要搜索所有的war文件来查找用户的请求的资源
webapps
1 2 |
|
含Web应用的程序 (JSP、Servlet等)
work
1 2 3 |
|
由Tomcat自动生成,这是Tomcat放置它运行期间的中间文件(诸如编译的JSP文件)地方。 如果当Tomcat运行时,你删除了这个目录那么将不能够执行包含JSP的页面。
3、Tomcat的配置文件
Tomcat的配置文件默认存放在$CATALINA_HOME/conf目录中,主要有以下几个:
server.xml
Tomcat的主配置文件,包含Service, Connector, Engine, Realm, Valve, Hosts主组件的相关配置信息;
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 |
|
-
Server : Tomcat Server 是整个 Catalina JSP/Servlet 容器,它是一个单件(Sinleton)。
1 |
|
-
Server的相关属性:
className: 用于实现此Server容器的完全限定类的名称,默认为org.apache.catalina.core.StandardServer;
port: 接收shutdown指令的端口,默认仅允许通过本机访问,默认为8005;
shutdown:发往此Server用于实现关闭tomcat实例的命令字符串,默认为SHUTDOWN;
Service : Service 是这样一个集合:它由一个或者多个 Connector 组成,并拥有一个负责处理所有Connector 所获得的客户请求的 Engine。
1 |
|
-
Service相关的属性:
className: 用于实现service的类名,一般都是org.apache.catalina.core.StandardService。
name:此服务的名称,默认为Catalina;
Connector : 一个 Connector 将在某个指定端口上侦听客户请求,并将获得的请求交给 Engine 来处理,从 Engine 处获得回应并返回客户。Tomcat 有两个典型的 Connector,一个直接侦听来自 web 浏览器的 HTTP 请求,一个侦听来自其它 WebServer 的请求
-
定义连接器可以使用多种属性,有些属性也只适用于某特定的连接器类型。一般说来,常见于server.xml中的连接器类型通常有4种:
1) HTTP连接器
2) SSL连接器
3) AJP 1.3连接器
4) proxy连接器
如上面示例server.xml中定义的HTTP连接器:
1
2
3
"8080"
protocol=
"HTTP/1.1"
connectionTimeout=
"20000"
redirectPort=
"8443"
/>
定义连接器时可以配置的属性非常多,但通常定义HTTP连接器时必须定义的属性只有“port”,定义AJP连接器时必须定义的属性只有"protocol",因为默认的协议为HTTP。以下为常用属性的说明:
1) address:指定连接器监听的地址,默认为所有地址,即0.0.0.0;
2) maxThreads:支持的最大并发连接数,默认为200;
3) port:监听的端口,默认为0;
4) protocol:连接器使用的协议,默认为HTTP/1.1,定义AJP协议时通常为AJP/1.3;
5) redirectPort:如果某连接器支持的协议是HTTP,当接收客户端发来的HTTPS请求时,则转发至此属性定义的端口;
6) connectionTimeout:等待客户端发送请求的超时时间,单位为毫秒,默认为60000,即1分钟;
7) enableLookups:是否通过request.getRemoteHost()进行DNS查询以获取客户端的主机名;默认为true;
8) acceptCount:设置等待队列的最大长度;通常在tomcat所有处理线程均处于繁忙状态时,新发来的请求将被放置于等待队列中;
上例中还定义了一个多个属性的SSL器:
1 2 3 |
|
Engine : Engine 是某个 service 中的请求处理机,它负责接收和处理来自 Connector 的请求。Engine 下可以配置多个虚拟主机(Virtual Host),每个虚拟主机都有一个域名。当 Engine 获得一个请求时,它将根据请求中的信息把该请求匹配到某个 Host 上,然后在该 Host 配置的环境下处理该请求。Engine 有一个默认虚拟主机,当请求无法匹配到任何一个 Host 上的时候,将交给该默认虚拟主机来处理。
1 |
|
-
常用的属性定义:
defaultHost:Tomcat支持基于FQDN的虚拟主机,这些虚拟主机可以通过在Engine容器中定义多个不同的Host组件来实现;但如果此引擎的连接器收到一个发往非非明确定义虚拟主机的请求时则需要将此请求发往一个默认的虚拟主机进行处理,因此,在Engine中定义的多个虚拟主机的主机名称中至少要有一个跟defaultHost定义的主机名称同名;
name:Engine组件的名称,用于日志和错误信息记录时区别不同的引擎;
Engine容器中可以包含Realm、Host、Listener和Valve子容器。
Host : 一个 Host 代表一个虚拟主机(Virtual Host),每个虚拟主机和某个域名(Domain Name)相匹配。每个虚拟主机下都可以部署(deploy)一个或者多个 web applications,每个 web application 对应于一个 Context,并拥有一个 Context path。当 Host 获得一个针对某个特定的 Host的请求时,将在该 Host 的环境下把请求匹配到某个 Context 上,然后把请求交给该 Context 来处理。Context 的匹配方法是 最长匹配 ,所以一个 “ ” path="" 的 Context 将成为该 Host 的默认 Context,所有无法和其它 Context 的路径名匹配的请求都将最终和该默认 Context 匹配。
1 2 |
|
-
常用属性说明:
1) appBase:此Host的webapps目录,即存放非归档的web应用程序的目录或归档后的WAR文件的目录路径;可以使用基于$CATALINA_HOME的相对路径;
2) autoDeploy:在Tomcat处于运行状态时放置于appBase目录中的应用程序文件是否自动进行deploy;默认为true;
3) unpackWars:在启用此webapps时是否对WAR格式的归档文件先进行展开;默认为true;
-
虚拟主机定义示例:
1 2 3 4 5 6 7 8 9 10 |
|
主机别名定义:
如果一个主机有两个或两个以上的主机名,额外的名称均可以以别名的形式进行定义,如下:
1 2 3 |
|
Context : 一个 Context 对应于一个 web application,一个 web application 由一个或者多个Servlet 组成。每个 Context 在创建的时候都将根据配置文件conf/web.xml 和 webapps/${webapp.home}/WEB-INF/web.xml 载入 Servlet 类和创建映射表(mapping table)。当Context 获得请求时,将在自己的映射表中寻找相匹配的 Servlet 类。如果找到,则执行该类,获得结果并返回。
例如(配置文件中默认没有此项)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
""
docBase=
"/web/webapps"
/>
"/bbs"
docBase=
"/web/threads/bbs"
reloadable=
"true"
>
<
/Context
>
"/chat"
docBase=
"/web/chat"
/>
"/darian"
docBase=
"darian"
/>
-
常用的属性定义有:
1) docBase:相应的Web应用程序的存放位置;也可以使用相对路径,起始路径为此Context所属Host中appBase定义的路径;切记,docBase的路径名不能与相应的Host中appBase中定义的路径名有包含关系,比如,如果appBase为deploy,而docBase绝不能为deploy-bbs类的名字;
2) path:相对于Web服务器根路径而言的URI;如果为空“”,则表示为此webapp的根路径;如果context定义在一个单独的xml文件中,此属性不需要定义;
3) reloadable:是否允许重新加载此context相关的Web应用程序的类;默认为false;
-
Realm组件:一个Realm表示一个安全上下文,它是一个授权访问某个给定Context的用户列表和某用户所允许切换的角色相关定义的列表。因此,Realm就像是一个用户和组相关的数据库。定义Realm时惟一必须要提供的属性是classname,它是Realm的多个不同实现,用于表示此Realm认证的用户及角色等认证信息的存放位置。
下面是一个常见的使用UserDatabase的配置:
1 2 3 |
|
JAASRealm:基于Java Authintication and Authorization Service实现用户认证;
JDBCRealm:通过JDBC访问某关系型数据库表实现用户认证;
JNDIRealm:基于JNDI使用目录服务实现认证信息的获取;
MemoryRealm:查找tomcat-user.xml文件实现用户信息的获取;
UserDatabaseRealm:基于UserDatabase文件(通常是tomcat-user.xml)实现用户认证,它实现是一个完全可更新和持久有效的MemoryRealm,因此能够跟标准的MemoryRealm兼容;它通过JNDI实现;
下面是一个使用JDBC方式获取用户认证信息的配置:
1 2 3 4 5 6 7 |
|
-
Valve组件:Valve类似于过滤器,它可以工作于Engine和Host/Context之间、Host和Context之间以及Context和Web应用程序的某资源之间。一个容器内可以建立多个Valve,而且Valve定义的次序也决定了它们生效的次序。Tomcat6中实现了多种不同的Valve:
1 2 3 |
|
AccessLogValve:访问日志Valve
ExtendedAccessValve:扩展功能的访问日志Valve
JDBCAccessLogValve:通过JDBC将访问日志信息发送到数据库中;
RequestDumperValve:请求转储Valve;
RemoteAddrValve:基于远程地址的访问控制;
RemoteHostValve:基于远程主机名称的访问控制;
SemaphoreValve:用于控制Tomcat主机上任何容器上的并发访问数量;
JvmRouteBinderValve:在配置多个Tomcat为以Apache通过mod_proxy或mod_jk作为前端的集群架构中,当期望停止某节点时,可以通过此Valve将用记请求定向至备用节点;使用此Valve,必须使用JvmRouteSessionIDBinderListener;
ReplicationValve:专用于Tomcat集群架构中,可以在某个请求的session信息发生更改时触发session数据在各节点间进行复制;
SingleSignOn:将两个或多个需要对用户进行认证webapp在认证用户时连接在一起,即一次认证即可访问所有连接在一起的webapp;
ClusterSingleSingOn:对SingleSignOn的扩展,专用于Tomcat集群当中,需要结合ClusterSingleSignOnListener进行工作;
RemoteHostValve和RemoteAddrValve可以分别用来实现基于主机名称和基于IP地址的访问控制,控制本身可以通过allow或deny来进行定义,这有点类似于Apache的访问控制功能;如下面的Valve则实现了仅允许本机访问/probe:
1 2 3 4 |
|
-
-
其中相关属性定义有:
-
1) className:相关的java实现的类名,相应于分别应该为org.apache.catalina.valves.RemoteHostValve或org.apache.catalina.valves.RemoteAddrValve;
2) allow:以逗号分开的允许访问的IP地址列表,支持正则表达式,因此,点号“.”用于IP地址时需要转义;仅定义allow项时,非明确allow的地址均被deny;
3) deny: 以逗号分开的禁止访问的IP地址列表,支持正则表达式;使用方式同allow;
-
GlobalNamingResources:应用于整个服务器的JNDI映射,此可以避免每个Web应用程序都需要在各自的web.xml创建,这在web应用程序以WAR的形式存在时尤为有用。它通常可以包含三个子元素:
1) Environment;
2) Resource;
3) ResourceEnvRef;
1 2 3 4 5 6 7 8 9 10 |
|
-
WatchedResource:WatchedResource可以用于Context中监视指定的webapp程序文件的改变,并且能够在监视到文件内容发生改变时重新装载此文件。
Listener:Listener用于创建和配置LifecycleListener对象,而LifecycleListener通常被开发人员用来创建和删除容器。
Loader:Java的动态装载功能是其语言功能强大表现之一,Servlet容器使用此功能在运行时动态装载servlet和它们所依赖的类。Loader可以用于Context中控制java类的加载。
Manager:Manger对象用于实现HTTP会话管理的功能,Tomcat6中有4种Manger的实现:
1) StandardManager:Tomcat6的默认会话管理器,用于非集群环境中对单个处于运行状态的Tomcat实例会话进行管理。当Tomcat关闭时,这些会话相关的数据会被写入磁盘上的一个名叫SESSION.ser的文件,并在Tomcat下次启动时读取此文件。
2) PersistentManager:当一个会话长时间处于空闲状态时会被写入到swap会话对象,这对于内存资源比较吃紧的应用环境来说比较有用。
3)DeltaManager:用于Tomcat集群的会话管理器,它通过将改变了会话数据同步给集群中的其它节点实现会话复制。这种实现会将所有会话的改变同步给集群中的每一个节点,也是在集群环境中用得最多的一种实现方式。
4)BackupManager:用于Tomcat集群的会话管理器,与DeltaManager不同的是,某节点会话的改变只会同步给集群中的另一个而非所有节点。
-
Stores:PersistentManager必须包含一个Store元素以指定将会话数据存储至何处。这通常有两种实现方式:FileStore和JDBCStore
Resources:经常用于实现在Context中指定需要装载的但不在Tomcat本地磁盘上的应用资源,如Java类,HTML页面,JSP文件等。
Cluster:专用于配置Tomcat集群的元素,可用于Engine和Host容器中。在用于Engine容器中时,Engine中的所有Host均支持集群功能。在Cluster元素中,需要直接定义一个Manager元素,这个Manager元素有一个其值为org.apache.catalina.ha.session.DeltaManager或org.apache.catalina.ha.session.BackupManager的className属性。同时,Cluster中还需要分别定义一个Channel和ClusterListener元素。
Channel:用于Cluster中给集群中同一组中的节点定义通信“信道”。Channel中需要至少定义Membership、Receiver和Sender三个元素,此外还有一个可选元素Interceptor。
Membership:用于Channel中配置同一通信信道上节点集群组中的成员情况,即监控加入当前集群组中的节点并在各节点间传递心跳信息,而且可以在接收不到某成员的心跳信息时将其从集群节点中移除。Tomcat6中Membership的实现是org.apache.catalina.tribes.membership.McastService。
Sender:用于Channel中配置“复制信息”的发送器,实现发送需要同步给其它节点的数据至集群中的其它节点。发送器不需要属性的定义,但可以在其内部定义一个Transport元素。
Transport:用于Sender内部,配置数据如何发送至集群中的其它节点。Tomcat6有两种Transport的实现:
1) PooledMultiSender:基于Java阻塞式IO,可以将一次将多个信息并发发送至其它节点,但一次只能传送给一个节点。
2)PooledParallelSener:基于Java非阻塞式IO,即NIO,可以一次发送多个信息至一个或多个节点。
-
Receiver:用于Channel定义某节点如何从其它节点的Sender接收复制数据,Tomcat6中实现的接收方式有两种BioReceiver和NioReceiver。
web.xml
遵循Servlet规范标准的配置文件,用于配置servlet,并为所有的Web应用程序提供包括MIME映射等默认配置信息;
tomcat-user.xml
Realm认证时用到的相关角色、用户和密码等信息;Tomcat自带的manager默认情况下会用到此文件;在Tomcat中添加/删除用户,为用户指定角色等将通过编辑此文件实现;
catalina.policy
Java相关的安全策略配置文件,在系统资源级别上提供访问控制的能力;
catalina.properties
Tomcat内部package的定义及访问相关的控制,也包括对通过类装载器装载的内容的控制;Tomcat6在启动时会事先读取此文件的相关设置;
logging.properties:
Tomcat6通过自己内部实现的JAVA日志记录器来记录操作相关的日志,此文件即为日志记录器相关的配置信息,可以用来定义日志记录的组件级别以及日志文件的存在位置等;
context.xml
所有host的默认配置文件
四、SHOP++网上商城系统安装
1、环境部署
需要安装mysql
1 2 3 4 5 6 |
|
修改/usr/local/tomcat/conf/server.xml
1 2 3 |
|
在站点目录(/usr/local/tomcat/webapps)中,新建一目录名为shop
1 |
|
将下载后网上商城解压到此下目录
1 2 3 4 5 |
|
重启tomcat服务
1 2 3 4 5 6 7 8 9 10 11 12 |
|
使用浏览器访问安装
环境检测
系统配置
系统安装
访问首页
子页测试
登录后台
后台管理
2、请求解析
请求被发送到本机端口 8080,被在那里侦听的 HTTP/1.1 Connector 获得
Connector 把该请求交给它所在的 Service 的 Engine 来处理,并等待来自 Engine 的回应
Engine 获得请求 localhost/yourContext/yourJSPPage.jsp,匹配它所拥有的所有虚拟主机 Host
Engine 匹配到名为 localhost 的 Host(即使匹配不到也把请求交给该 Host 处理,因为该 Host 被定义为该 Engine 的默认主机)
localhost Host 获得请求/yourContext/yourJSPPage.jsp,匹配它所拥有的所有 Context(最长匹配)
Host 匹配到路径为/yourContext 的 Context(如果匹配不到就把该请求交给路径名为""的 Context 去处理)
path="/yourContext"的 Context 获得请求/yourJSPPage.jsp,在它的 mapping table 中寻找对应的Servlet
Context 匹配到 URL pattern 为*.jsp 的 Servlet,对应于 JspServlet 类
构造 HttpServletRequest 对象和 HttpServletResponse 对象,作为参数调用 JspServlet 的 doGet或 doPost 方法(调用什么方法取决于来自客户的 HTTP 请求是 GET 请求还是 POST 请求)
Context 把执行完了之后的 HttpServletResponse 对象返回给 Host
Host 把 HttpServletResponse 对象返回给 Engine
Engine 把 HttpServletResponse 对象返回给 Connector
Connector 把 HttpServletResponse 对象返回给客户的 web 浏览器
本文转自 jinlinger 51CTO博客,原文链接:http://blog.51cto.com/essun/1409616,如需转载请自行联系原作者