灿烂的阳光,苦涩的生活,认真做,你能行!

发布新日志

  • windows apache 配置多个服务 站点 Apache Service Monitor

    2009-09-30 14:52:23

    更改第一个站点的根目录:在文件Apache2.2\conf\httpd.conf中查找 DocumentRoot 属性,将后面的路径改为你的主站点的路径,如:D:\www\web1

    为第二个Apache服务建立配置文件:复制并重命名httpd.conf为web2.conf(举个例子而已,也可以叫my.conf等等),修改web2.conf中的Listen 8080(原来为80)、ServerName localhost:8080(原来为80)、DocumentRoot "D:/www/web2" (原来为web1)
    添加第二个Apache服务:Apache安装目录的bin子目录下,使用如下命令将Apache安装为Windows NT服务:httpd.exe -k install -n "服务名" -f "d:\apache2.2\conf\web2.conf"
    其他的命令:
    将Apache安装为Windows NT服务:
    httpd -k install
    指定服务的名称,当你在同一机器上安装多个Apache服务时,你必须为它们指定不同的名字。
    httpd -k install -n "服务名"
    为不同名称的服务使用不同的配置文件,则安装时需要指定配置文件:
    httpd -k install -n "服务名" -f "c:\files\my.conf" 如果你使用的是第一个命令,也就是除 -k install 外没有其它命令行参数,那么被安装的服务名称将是:Apache2 ,配置文件将使用conf\httpd.conf 。
    移除一个Apache服务:
    httpd -k uninstall
    使用下述命令移除特定名称的Apache服务:
    httpd -k uninstall -n "服务名"
    通常,启动、重启、关闭Apache服务的方法是使用Apache Service Monitor工具,另外也可以使用控制台命令:NET START Apache2 和 NET STOP Apache2 或者通过Windows服务控制面板。在启动Apache服务之前,你应当使用下面的命令检查一下配置文件的正确性:
    httpd -n "服务名" -t
    你可以通过命令行开关来控制Apache服务。要启动一个已经安装的Apache服务,可以使用:
    httpd -k start
    要停止一个已经安装的Apache服务,可以使用:
    httpd -k stop

    httpd -k shutdown
    要重启一个运行中的Apache服务,强制它重新读取配置文件,可以使用:
    httpd -k restart

  • Windows Media Load Simulator使用步骤

    2009-01-21 16:36:12

    1 安装Windows Media Load Simulator

    2配置windows media service

    3C:\wmpub\WMRoot下放置WMLoad.asf
  • 教你用专业软件测试媒体服务器--设定Windows Media Load Simulator

    2009-01-21 16:17:02

    设定Windows Media Load Simulator

      设定Windows Media Load Simulator,要指定将要测试的服务器,要作为流的内容的来源和用户的配置。这一节对于如何配置Windows Media Load Simulator提供了一个总览;要了解全部的细节,请浏览Windows Media Load Simulator帮助。

    1.开启Windows Media server下载测试

      运行Windows Media Load Simulator,你必须复制一个名为WMLoad.asf的文件到服务器的Windows系统的%systemdrive%\Wmpub\Wmroot根目录下。这个文件提供了一个机制来帮助保护你的计算机不受未被授权的下载模拟的测试。在你完成运行下载模拟器测试后,简单的移动这个文件来防止恶意用户运行下载测试在你的服务器上。假如没有这个机制的保护,举个例子,一个因特网上的用户,向你的服务器模仿成千上万的用户连接,那个可以防止其他的连接到这个流和潜在的过载到你的系统。如果你想用Windows Media Load Simulator作为在线监控,那么将这个文件放在根目录下并且要通过发布点安全来限制对它的访问。

      要创建这个文件,用任意一个小文件只要扩展名是.asf的文件然后重命名为WMLoad.asf。同样的,要确保允许新的单一投放(unicast)连接在Windows媒体设备中对于默认的发布点是可用的。

    2.指定一个要进行测试的Windows媒体服务器

      无论是Configuration Wizard或是Load Test Configuration(Advanced)对话框,选择你想测试的Windows媒体服务器或服务器群的静态IP地址或fully qualified domain name(FQDN)类型。

    3.指定源内容

      添加源内容到Stream目录。这个列表包括了文件或者是动态流,你可以指定Windows Media Load Simulator是连续的或是随机的播放这些条目。

    你也必须要指定模拟器是否要使用微软媒体服务器(MMS)草案来流向,实时流草案(RTSP),超文本传输草案(HTTP),或者联合的草案。如果你只想通过应用Transport Control协议(TCP)来测试流动,指定MMST,RTSPT,或者两者。如果你应用MMS或RTSP作为协议,模仿用户可以使用协议rollover。这意味着如果一个用户不能通过MMS连接,还可以“滚动越过”去使用RTSPU来代替。另外,如果一个用户不能用RTSP来连接,也可以滚动越过去使用RTSPU。

    4. 创建用户信息

      一个用户的情况决定了一个模拟的用户回放行为。对于每种情况的用户键入一系列用户来创造一个全面的用户情况。你所键入的全部用户的数量不能超过在计算机上运行着的Windows Media Load Simulator的容量。全部的从所有模拟计算机连接到你的服务器的用户数需要和所有的你所估计的典型峰值客户下载的并发连接数目相等。下面的表格描述了每种信息:

    播放。模拟用户播放,停止或重启流

    长时播放。模拟用户连续播放一个流。如果内容是一个文件,用户就在文件结束时重复回放

    打开/关闭。模拟用户打开一个流但是播放前关闭它

    寻找。模拟用户向前或向后寻找一个流,或者如果这个内容是一个服务器面的播放列表,则跳过不同的播放列表条目。如果这个内容是一个活动的流或者是一个没有在索引里的文件,则客户无须寻找就可以播放它

    选择。模拟用户打开一个流,然后或者是用随机选择的一个比特速率(如果内容是多比特率内容)或者是用编码比特率(如果内容是单一比特率内容)来播放它

    随机。模拟用户可以浏览内容,在随意的时间长度里播放内容在内容中寻找,停止回放,暂停回放或有时关闭。

      如果你已经把所有的估计用户下载定为100,并且希望客户一直按照一种方式播放,你就可以,比如说,键入下面这些客户情况设置:


    Client Type

    Setting

    Play

    5

    Long play

    90

    Open/Close

    5

      如果你的典型内容是短新闻或者歌曲片断并且所有的并发用户下载预期为800,你就可以键入下面的客户情况设置:

    Client Type

    Setting

    Play

    60

    Long play

    40

    Seek

    60

    Open/close

    40

    5. 添加验证

      用户可以被设置验证来获得对服务器上被Windows Media publishing point security保护的内容的访问权。要测试验证,你可以在每一个文件或publishing points上设置访问权,然后模拟用户试图访问内容。你必须要把Windows Media server和在计算机上运行的用作验证测试的Windows Media Load Simulator都做设置。如果你想可以在服务器上运行WMS Digest验证,你需要设置Windows Media Load Simulator使用适当的用户名和密码。要了解更多的关于publishing point security的信息,请参见Windows Media Services帮助。

    6. 键入测试的持续时间和可用的记录

      你可以在小时,分钟和秒中指定一个时间间隔,或者你可以指定Windows Media Load Simulator在一定数量的错误后有一个停顿。你也可以无限期的运行这个测试。

      你可以装置Windows Media Load Simulator来创建两个日志,一个Windows Media Load Simulator日志文件和一个服务器性能表现日志文件,并且指定这两个文件的位置。在大多数情况里,你需要创建全部的日志。通过使用这两个日志和Windows Media Server日志来相互参照信息,你可以很好的理解在一个测试运行时系统是如何工作的。记下为了用户计算机从Windows Media server收集数据,被用户计算机记录下的用户必须在这个服务器上有管理权和许可。

    小结:

      本文到这里暂时告一段落,在下次的文章中我们将针对运行测试、设置在线镜像及一些常见问题进行整理,欢迎对Windows媒体服务器测试感兴趣的用户继续关注服务器频道近期的文章。

  • Tomcat相关的内存设置和优化

    2009-01-06 10:10:54

    1、JDK内存优化: 

    Tomcat默认可以使用的内存为128MB,Windows下,在文件{tomcat_home}/bin/catalina.bat,Unix下,在文件{tomcat_home}/bin/catalina.sh的前面,增加如下设置: 

    JAVA_OPTS='-Xms[初始化内存大小] -Xmx[可以使用的最大内存] 

    参数
     描述 
     
    -Xms
     JVM初始化堆的大小
     
    -Xmx
     JVM堆的最大值,一般说来,你应该使用物理内存的80% 作为堆大小。 
     
      

    有三种方法:

    1)就需要在环境变量中加上TOMCAT_OPTS, CATALINA_OPTS两个属性, 如 SET CATALINA_OPTS= -Xms64m -Xmx512m; ms是最小的,mx是最大,64m, 512m分别是指内存的容量. 

    2)修改Catalina.bat文件 在166行“rem Execute Java with the applicable properties ”以下每行 %_EXECJAVA% %JAVA_OPTS% %CATALINA_OPTS% %DEBUG_OPTS% -Djava.endorsed.dirs="%JAVA_ENDORSED_DIRS%" -classpath "%CLASSPATH%" -Dcatalina.base="%CATALINA_BASE%" -Dcatalina.home="%CATALINA_HOME%" -Djava.io.tmpdir="%CATALINA_TMPDIR %" %MAINCLASS% %CMD_LINE_ARGS% %ACTION% 中的%CATALINA_OPTS% 替换成 -Xms64m -Xmx512m 

    3)编辑%CATALINA_HOME%\bin下面的catalina.bat文件,在最上面第一行前面写上 set CATALINA_OPTS=-Xms512m -Xmx1024m set JAVA_OPTS=-Xms512m -Xmx1024m 

    其中-Xms表示jvm最小内存数,-Xmx表示最大内存数 比如我这里都设置成最小512,最大1024 当然,这个最小最大并不是只能使用1024的意思,其实这个设置是对系统来设置的,因为这个jvm占用内存数实际上是针对虚拟内存来说,这个设置表示,无 论系统怎么占用虚拟内存,都要保证最小512M的虚拟内存共给jvm使用,当然,就算我jvm占用再大,也不会超过1024,来威胁系统的内存使用

    2、连接器优化:

        在tomcat配置文件server.xml中的配置中,和连接数相关的参数有:

        maxThreads:

        Tomcat使用线程来处理接收的每个请求。这个值表示Tomcat可创建的最大的线程数。默认值200。

        acceptCount:

        指定当所有可以使用的处理请求的线程数都被使用时,可以放到处理队列中的请求数,超过这个数的请求将不予处理。默认值10。

        minSpareThreads:

        Tomcat初始化时创建的线程数。默认值4。

        maxSpareThreads:

        一旦创建的线程超过这个值,Tomcat就会关闭不再需要的socket线程。默认值50。

        enableLookups:

        是否反查域名,默认值为true。为了提高处理能力,应设置为false

        connnectionTimeout:

        网络连接超时,默认值60000,单位:毫秒。设置为0表示永不超时,这样设置有隐患的。通常可设置为30000毫秒。

        maxKeepAliveRequests:

        保持请求数量,默认值100。

        bufferSize:

        输入流缓冲大小,默认值2048 bytes。

        compression:

        压缩传输,取值on/off/force,默认值off。

        其中和最大连接数相关的参数为maxThreads和acceptCount。如果要加大并发连接数,应同时加大这两个参数。web server允许的最大连接数还受制于操作系统的内核参数设置,通常Windows是2000个左右,Linux是1000个左右。

     

        3、tomcat中如何禁止和允许列目录下的文件

        在{tomcat_home}/conf/web.xml中,把listings参数设置成false即可,如下:
     xml 代码
        <servlet>

                     ...

                     <init-param>

                     <param-name>listingsparam-name>

                     <param-value>falseparam-value>

                     <init-param>

                     ...

        <servlet>

        <servlet>

                     ...

                     <init-param>

                     <param-name>listingsparam-name>

                     <param-value>falseparam-value>

                     <init-param>

                     ...

        <servlet>   4、tomcat中如何禁止和允许主机或IP地址访问
                   view plaincopy to clipboardprint?
        <Host name="localhost" ...>
              ...

                   <Valve className="org.apache.catalina.valves.RemoteHostValve"

                   allow="*.mycompany.com,www.yourcompany.com"/>

                   <Valve className="org.apache.catalina.valves.RemoteAddrValve"

                   deny="192.168.1.*"/>

                   ...

        <Host>

          <Host name="localhost" ...>
                ...

                     <Valve className="org.apache.catalina.valves.RemoteHostValve"

                     allow="*.mycompany.com,www.yourcompany.com"/>

                     <Valve className="org.apache.catalina.valves.RemoteAddrValve"

                     deny="192.168.1.*"/>

                     ...

          <Host>
             JAVA_OPTS='-server -Xms512m -Xmx768m -XX:NewSize=128m -XX:MaxNewSize=192m -XX:SurvivorRatio=8'

     

    一般说来,我们启动Tomcat是在Windows服务里,所以修改内存和堆栈等参数应该在注册表里,在bat文件里修改不会起作用。

  • 网管经验谈:远程桌面中断巧解决

    2009-01-05 11:51:16

    远程桌面的使用非常简单,通过远程桌面连接程序访问目标计算机,输入用户名和密码后登录成功后就和使用自己的计算机一模一样了。不过最近笔者在对一台XP系统计算机进行管理时,却出现了无法正常连接的问题。最后通过查询资料解决了此问题,在此写出来给各位读者,希望大家在遇到同样问题时能够快速解决。

      一、远程桌面连接故障现象

      笔者刚刚安装完一台员工计算机,该计算机操作系统是windows XP,领导决定以后这台计算机就担任公司数据存放工作,所以日后需要对其进行远程管理操作。所以笔者也像往常一样,开启了该系统的远程桌面连接功能。谁知道在网络中的其他计算机通过远程桌面连接程序访问时却出现了“中断远程桌面连接,远程计算机已结束连接”的提示,也就是说能够连接上但是马上中断,根本没有给予输入管理员用户名和密码的时间。

      二、解决问题

      既然可以连接到该计算机,只是马上中断。笔者怀疑是否在远程桌面登录时是默认使用当前帐户的,所以将自己的计算机帐户和密码设置为和远程那台计算机一致,谁知道问题依旧。看来故障应该是该计算机远程桌面服务本身的设置问题。笔者在网上寻求帮助,终于发现了问题的所在。

      第一步:通过“开始->运行->输入regedit”,打开注册表编辑器。

      第二步:打开注册表后找到[HKEY_LOCAL_MACHINESYSTEMControlSet001EnumRootRDPDR键值,在左侧的RDPDR上点鼠标右键,选择“权限”。

      第三步:在弹出的对RDPDR设置权限窗口后,将everyone组添加到完全控制权限,如果你只想让某个特定的用户远程管理该计算机的话,将该帐户添加到权限设置窗口中即可,记住一定要给予“完全控制”权限。

      第四步:接下来将如下内容复制到一个记事本txt文件中,并保存成后缀为.reg的文件。例如笔者保存成111.reg。

      Windows Registry Editor Version 5.00

      [HKEY_LOCAL_MACHINESYSTEMControlSet001EnumRootRDPDR000]

      "ClassGUID"="{4D36E97D-E325-11CE-BFC1-08002BE10318}"

      "Class"="System"

      "HardwareID"=hex(7):52,00,4f,00,4f,00,54,00,5c,00,52,00,44,00,50,00,44,00,52,

      00,00,00,00,00

      "Driver"="{4D36E97D-E325-11CE-BFC1-08002BE10318}030"

      "Mfg"="(标准系统设备)"

      "Service"="rdpdr"

      "DeviceDesc"="终端服务器设备重定向器"

      "ConfigFlags"=dword:00000000

      "Capabilities"=dword:00000000

      第五步:接下来我们双击运行保存后的注册表文件111.reg,当出现“注册表导入成功”的提示后说明我们操作正确。

      第六步:再通过“开始->运行->输入services.msc”,打开服务管理窗口,找到名为“Remote Desktop Help Session Manager ”和“Telnet”的服务。

      第七步:在这两个服务名称上点鼠标右键选择“启动”,将服务开启。

      第八步:重新启动计算机后我们再通过远程桌面连接程序访问此台计算机就不会再出现任何问题了,程序自动进入输入管理员帐号和密码的步骤。

      至此我们通过启动服务和导入注册表,以及修改注册表键值使用权限三个步骤完成了解决一连接远程桌面程序就中断的故障,我们又可以轻松正常的使用远程管理程序操纵网络另一端的计算机了。

      总结

      这个故障实际上是因为在安装操作系统时,使用了精简版XP GHOST或网络流传的XP万能GHOST造成的,在这些GHOST中默认将远程桌面程序关闭了,并对一些必要的注册表键值使用权限进行了修改。虽然对于普通家庭个人用户来说能够提高安全,防止非法用户通过远程桌面连接计算机,但是对企业来说则会带来一定的不方便。所以笔者建议各位网络管理员在以后安装员工计算机操作系统时,尽量选择那些没有精简过的XP GHOST或者直接使用系统光盘进行安装,毕竟GHOST在使用上或多或少存在一定的问题。

  • Tomcat5中的部署方式

    2008-12-17 16:08:27

    Tomcat4中的部署方式:

    1 部署Web应用程序的方法:
    1.1 WAR方式
    将应用程序包含的jsp、servlet等文件包装成一个单个的、自包含的WAR文件。WAR文件是一个JAR文件,其中包含了特殊的目录和位于他的/Web-INF目录中的web.xml文件。其结构举例如下:
    hello.jsp
    META-INF/
          MANIFEST.MF
    Web-INF/
          web.xml
          classes/
                example/helloWorld.class
          lib/
                xxx.jar
    创建WAR文件的最容易的方法就是,首先在开发环境中创建相应于WAR结构的目录结构。然后,创建WAR所要做的工作就是在WAR的根目录中执行下面的命令。注意,其中排除了.java源文件,它是WAR文件中不必要的内容,并且在试图部署WAR时可能会带来问题:
    Jar ?cvf hello.war META-INF/MANIFEST.MF Web-INF/classes/example/*.class Web-INF/web.xml *.jsp
    将WAR文件拷贝到$CATALINA_HOME/webapps目录中。当Tomcat启动时,它
    就会自动对WAR文件进行解包,并且创建这个应用程序,应用程序的名字(和上下文路径Context Path)为WAR文件的名称。在这里不需要对系统或者服务器路径做任何的改动。

    注意:如果在Tomcat已经启动好以后,放置WAR文件到webapps目录,则Tomcat无法动态
    部署这个Web应用程序,需要重启Tomcat。 如果虚拟主机的liveDeploy属性为true就不用了。

    1.2扩展目录方式
    此种部署方式的优点是,当对jsp进行了修改时不必重启Tomcat,并且不必在每次修改时都要去重新建立归档文件,而且在准备好进行软件分发时也很容易地创建WAR文件。
      在server.xml文件中加入如下代码,该文件位于$CATALINA_HOME/conf目录中。
      <Context path=”/hello” docBase=”<path to root of war>” debug=”0”
            reloadable="true" crossContext="true" />
      <path to root of war>是一个按照使用的操作系统的目录惯例的绝对路径,并且不必是位于Tomcat的目录树下面。作者把这个WAR部署到Windows中,使用的是docBase=”d: lymacy”,而在Unix中,所使用的docBase=”/export/home/macy”。

    注意,Tomcat要求对Windows的路径使用单个反斜杠。

    ______________________________________________________________________________________________
    答6:
    Tomcat5中的部署方式:


    1 应用程序部署器(Deployer)
    程序员朋友不要以为这是什么全新的东西,其实以前的版本就已经有了,只不过在Tomcat4中没有提出这个概念,且它的功能被分散在各个组件中,给人的感觉是比较支离破碎的。于是乎,在Tomcat5中对其进行了包装和增强,提出了Deployer这个逻辑概念,用于集中表示应用程序部署和发布功能。Tomcat5对其的主要改进就是进行了一些优化,增强了动态部署的功能,减少了重启Tomcat的次数,增强了服务器的健壮性和可靠性。
    Deployer提供的主要功能就是静态(在tomcat启动之前)或者动态(在Tomcat运行以后)进行Web应用程序的部署和删除,在某些情况下Deployer需要和Manager管理工具联合使用。
    1.1 Context descrīptors
    这个也不是新东西了,Tomcat4中的Manager和Admin管理工具其实就是利用它来部署的。在Tomcat5中提出了Context descrīptor这个概念,且为其配置了一个专有目录,而不像Tomcat4那样大杂烩一般地放置在$appBase目录下。既然了有了名分,当然要为其单独配置一个目录才能显其身份:)
    Context descrīptor是一个只包含Context元素的xml格式的部署文件,其中Context元素与server.xml中的Context元素配置相同。对于一个给定的主机,Context descrīptor放置在$CATALINA_HOME/conf/[enginename]/[hostname]/目录下面。Tomcat5默认安装时,在$CATALINA_HOMEconfCatalinalocalhost目录中有admin.xml和manager.xml,是两个管理工具的部署描述符文件。而这两个文件在Tomcat4中是放置在$CATALINA_HOME/webapps目录下面的。呵呵。。。果然是换汤不换药啊:)

    注意事项:context descrīptor的文件名可以与Web应用程序名无关,但是Tomcat在部署这个应用程序的时候所创建的程序运行上下文(Context)的名称是与Web应用程序名称匹配的。
     
    1.2 静态部署
    静态部署是指在Tomcat运行之前就把相关的Web应用程序放置到合适的目录,在Tomcat启动的时候自动来部署这些应用程序。
    如果"deployOnStartup"属性值为true,那么在Tomcat启动时,在$appBase目录下的web应用程序将被自动部署。部署的过程如下:
    ? Context元素声明的Web应用程序将被首先部署,这包括server.xml和context descrīptor文件中的Context元素所指的应用程序;
    ? 部署扩展目录形式的Web应用程序;
    ? 部署WAR形式的Web应用程序;
    Tomcat5对于静态方式的部署的增强主要就是:
    1、对于context descrīptor方式的应用程序的部署。
    2、如果扩展目录方式的应用程序对应有一个WAR文件,且WAR是更新过的,扩展目录将被自动删除,Web应用程序将被从WAR文件中重新部署。而在Tomcat4中,即使WAR文件已更新也无法被重新部署,仍然会使用旧的扩展目录方式的Web应用程序,除非你自己手动删除目录,记得还要重启Tomcat哦。这么麻烦?(#@($)#*$),看来还是Tomcat5好啊:)

    1.3 动态部署
    动态部署是指在Tomcat已经运行以后在不重启服务器的情况下部署应用程序的方式。
    如果虚拟主机的"autoDeploy"属性值为true,则主机会在需要的时候试图去部署和更新应用程序。这是由虚拟主机在后台运行的一个负责自动加载的处理线程来完成的,它的工作流程如下:
    1、部署新放入$appBase目录的War方式的应用程序。
    2、部署新放入$appBase目录的扩展目录方式的应用程序。
    3、如果一个扩展目录方式的应用程序对应的War文件更新了,则删除此目录,从War文件中重新解开并部署。如果”unpackWARs”属性值为false,则不解开,从War文件中直接运行。(记住:不用自己删除扩展目录,也不用重启服务器)
    4、如果应用程序的/WEB-INF/web.xml文件被改变,则重新部署这个应用。
    5、如果应用程序对应的Context元素配置发生了改变,则重新部署这个应用。这包括server.xml或者上下文描述符文件中的Context元素。
    6、如果$CATALINA_HOME/conf/[enginename]/[hostname]/目录下增加了上下文描述符文件,则重新部署这个应用。
    看来Tomcat5在动态部署上花费了不少功夫,其中的亮点主要就是如果我们修改了web.xml、server.xml配置文件,增加了上下文描述符文件,动态更新了War文件时都可以实现应用程序的自动部署和更新,而不用重新启动Tomcat服务器,在Tomcat4中都是必须重新启动服务器的,这是一个非常喜人的变化。毕竟在对服务器的健壮性和可靠性要求越来越高的今天,重启服务器都是一件令我们非常头疼的一件事情。以后终于可以挺直腰杆对客户说“这回坚决不用重启服务器!”嘿嘿。。。幸福啊!

    1.4 用Client Deployer工具包部署
      这个才是Tomcat5中名副其实的创新,它是一个全新的部署器。
    client deployer是一个集验证、编译、部署功能与一体的工具包。它使用Ant来实现应用程序的自动化验证和编译,使用Manager管理工具来实现应用程序的自动化部署。
    这个工具包包含:Catalina Ant工具、Jasper编译器(用于将jsp编译为servlet)、应用程序验证工具(validator task)。默认的验证工具的实现类是org.apache.catalina.ant.ValidatorTask,它只允许以扩展目录的文件路径作为唯一的参数。
    此部署工具包使用一个事先写好的Ant脚本,包含如下一些目标(target):
    ? compile (默认):用于验证和编译Web应用程序。它可以在不启动Tomcat的情况下被单独使用。由于使用的是新的Jasper编译器的缘故,编译后的应用程序将只能在Tomcat 5.X版本上使用。需要提醒的是,不光是jsp文件被编译为servlet, 应用程序的/WEB-INF/classes目录下的Java源文件也将被同时编译为class文件。
    ? deploy:将Web应用程序部署到Tomcat服务器中。
    ? undeploy:从服务器中解除部署已经部署的某个应用程序。
    ? start:启动Web应用程序
    ? reload:重新加载Web应用程序
    ? stop:停止Web应用程序

    以下是Ant脚本中的一些重要属性:
    ? build:编译以后的文件默认放置在${build}/webappapp/web。编译目标执行完以后,生成了应用程序的War —— ${build}/webappapp/web.war.
    ? webapp:放置需要被验证和编译的Web应用程序(扩展目录方式)的文件路径。默认值为”myapp”。
    ? path:Web应用程序部署后对应的运行上下文的路径默认是”/myapp“。
    ? url:放置Manager管理工具的绝对路径,它被部署工具包用来部署和解除部署应用程序。默认情况下,部署器将试图使用
    http://localhost:8080/manager访问本机的Manager管理工具。
    ? username:可以使用Manager管理工具的超级用户的用户名。
    ? Password:超级用户的密码。

    至此,Tomcat5中神秘的部署器就讲完了,大家是不是已经对它发生了浓厚的兴趣呢?那就动手去试一下吧!尽管朝$appBase目录下扔你心爱的程序吧,Tomcat5会马上让他们欢快地跑起来。速度真的比Tomcat4快多了,一种冲浪的感觉:)
  • tomcat配置方法 共有0条回复

    2008-12-17 15:12:22

    一、tomcat 的 context元素 配置

    如果将做好的web程序再tomcat总发布,那我们必须要了解Tomcat 体系结构中的六个主要概念:Server Service Engine Host Connector Context ,其中我认为context是使用最频繁的元素我们初学者首先要了解的。

    Context表示在虚拟主机中运行的web应用程序。一个虚拟主机中能够运行多个Context,它们通过各自的Context Path进行相互区分。如果Context Path为"",那么该web应用为该虚拟主机的默认的web应用。实际上context作用和在iis中配置的虚拟目录一样,只不过微软东西做的有界面,而我们需要手工配置,但是如果将manager应用启动后我们也可以在界面下配置。

    context怎么配置呢,目前可以通过四种方式将Context加入Host:

    1、$CATALINA_HOME/conf/context.xml,其中Context元素中的信息会被所有web应用程序加载

    2、$CATALINA_HOME/conf/[enginename]/[hostname]/context.xml.default,其中Context元素中的信息会被hostname主机下的所有web应用程序加载

    3、$CATALINA_HOME/conf/[enginename]/[hostname]/目录中所有以.xml为扩展名的文件,其中Context元素中的信息会被hostname主机下的所有web应用程序加载

    4、如果通过上面的步骤没有找到,那么最后要从web应用程序的/meta-INF/context.xml目录中查找

    tomcat 与 java Web 开发技术详解》中讲到配置context元素的方法(第16页),但是这个方法目前在tomcat6中是不推荐使用的,甚至在tomcat6的使用说明中都不这么写了,所以大家不要按照书上的方法设置了。

    tomcat6 具有 Automatic Application Deployment 功能,所以一般情况下你只要设置正确 那么在浏览器中敲入:

    http://127.0.0.1:8080/examples/ 就可以看到tomcat自带的例子程序,如果你有新开发的web应用并且是按照tomcat的标准的目录结构,

    那么不需要任何配置,只要把发布的文件夹考到webapp下就可以了。打开“Automatic Application Deployment 功能”的参数为

    使用Host的标准实现,同时deployonstartup属性值为true(这是默认值)。

    自动部署功能已经够用了,后面会详细降到自动部署的细节。

    现在对上述的前三种方法做一个说明,第四种没什么可说的:

    1、第一种方法,《tomcat 与 java Web 开发技术详解》(第16页)中讲到配置context元素,可以在/conf/server.xml 中的 元素中 加入 这种方法现在已经不推荐使用了,同时这个方法演变为在$CATALINA_HOME/conf/context.xml 文件中加入context 配置

    2。第二、三种方法 区别不大,但是用的人不多,最典型的就是Netbeans6 绑定的tomcat 就是用这种方式部署应用的,如果安装了Netbeans的网友可以到C:\Documents and Settings\用户名\.netbeans\6.0\apache-tomcat-6.0.14_base\conf\Catalina\localhost 看到manager.xml 及root.xml 这些xml中的context元素的 path 参数 指定的是实际的web应用的程序所在的目录,netbeans都用的是绝对路径。

    二 、自动部署 (Automatic Application Deployment)的细节。

    如果使用Host的标准实现,同时deployonstartup属性值为true(这是默认值),那么Catalina在首次启动时会自动完成下面的工作:

    $CATALINA_HOME/conf/[engine_name]/[host_name]目录下的所有xml文件都被假定含有元素。

    appbase目录下的所有没有展开的war文件(没有展开的意思是没有和war文件名不包括.war扩展名对应的目录存在)会被自动展开,除非unpackWARs属性值为false。如果重新部署更新的war文件,在重起Tomcat之前要删除先前展开的目录(如果autoDeploy属性值为true那么只要删除先前展开的目录更新后的war文件就会自动展开)。

    对于appbase中含有/WEB-INF/web.xml文件的任何子目录都会自动产生一个Context,不管该子目录是否在conf/server.xml文件中出现过。这个新产生的Context将会根据DefaultContext的属性值进行设置,其context path为“/目录名”。

    如果目录名为ROOT,那么context path为“”。

    因此要使用上面的规则需要将xml设置文件拷贝到$CATALINA_HOME/conf/[engine_name]/[host_name]目录下或将war文件和含有web应用的目录拷贝到appbase目录下。

    自动部署(Auto Deployer)也会跟踪如下web应用程序的变化:

    更新WEB-INF/web.xml文件将会使web应用程序重新加载

    更新已展开的war文件会使web应用程序卸载(undeploy)(同时移除先前展开的目录)并重新部署(deployment)

    更新xml设置文件会使web应用程序卸载(undeploy)(不移除任何展开的目录)并重新部署(deployment)

    在使用自动部署的时候xml设置文件中的docbase要指向appbase目录之外。否则部署将很困难或应用程序会被部署两次。

    如果要显示的定义context,那么需要关闭自动部署。否则相应的context将会部署两次,这可能会有问题。

  • JAVA基础-Tomcat的配置技巧精华详解

    2008-12-17 15:10:45

    1、配置系统管理(Admin Web Application)
      
      大多数商业化的J2EE服务器都提供一个功能强大的管理界面,且大都采用易于理解的Web应用界面。Tomcat按照自己的方式,同样提供一个成熟的管理工具,并且丝毫不逊于那些商业化的竞争对手。Tomcat的Admin Web Application最初在4.1版本时出现,当时的功能包括管理context、data source、user和group等。当然也可以管理像初始化参数,user、group、role的多种数据库管理等。在后续的版本中,这些功能将得到很大的扩展,但现有的功能已经非常实用了。Admin Web Application被定义在自动部署文件:CATALINA_BASE/webapps/admin.xml 。(译者注:CATALINA_BASE即tomcat安装目录下的server目录)
      
      你必须编辑这个文件,以确定Context中的docBase参数是绝对路径。也就是说,CATALINA
      
      _BASE/webapps/admin.xml的路径是绝对路径。作为另外一种选择,你也可以删除这个自动部署文件,而在server.xml文件中建立一个Admin Web Application的context,效果是一样的。你不能管理Admin Web Application这个应用,换而言之,除了删除CATALINA_BASE/webapps/admin.xml ,你可能什么都做不了。
      
      如果你使用UserDatabaseRealm(默认),你将需要添加一个user以及一个role到CATALINA_BASE/conf/tomcat-users.xml文件中。你编辑这个文件,添加一个名叫“admin”的role 到该文件中,如下:
      
      <role name="admin"/>
      
      你同样需要有一个用户,并且这个用户的角色是“admin”。象存在的用户那样,添加一个用户(改变密码使其更加安全):
      
      <user name="admin"
      password="deep_dark_secret"
      roles="admin"/>
      
      当你完成这些步骤后,请重新启动Tomcat,访问http://localhost:8080/admin,你将看到一个登录界面。Admin Web Application采用基于容器管理的安全机制,并采用了Jakarta Struts框架。一旦你作为“admin”角色的用户登录管理界面,你将能够使用这个管理界面配置Tomcat。
      
      2、配置应用管理(Manager Web Application)
      
      Manager Web Application让你通过一个比Admin Web Application更为简单的用户界面,执行一些简单的Web应用任务。Manager Web Application被被定义在一个自动部署文件中:
      
      CATALINA_BASE/webapps/manager.xml
      
      你必须编辑这个文件,以确保context的docBase参数是绝对路径,也就是说CATALINA_HOME/server/webapps/manager的绝对路径。(译者注:CATALINA_HOME即tomcat安装目录)
      
      如果你使用的是UserDatabaseRealm,那么你需要添加一个角色和一个用户到CATALINA_BASE/conf/tomcat-users.xml文件中。接下来,编辑这个文件,添加一个名为“manager”的角色到该文件中:
      
      <role name=”manager”>
      
      你同样需要有一个角色为“manager”的用户。像已经存在的用户那样,添加一个新用户(改变密码使其更加安全):
      
      <user name="manager"
      password="deep_dark_secret"
      roles="manager"/>
      
      然后重新启动Tomcat,访问http://localhost/manager/list,将看到一个很朴素的文本型管理界面,或者访问http: //localhost/manager/html/list,将看到一个HMTL的管理界面。不管是哪种方式都说明你的Manager Web Application现在已经启动了。
      
      Manager application让你可以在没有系统管理特权的基础上,安装新的Web应用,以用于测试。如果我们有一个新的web应用位于/home/user /hello下在,并且想把它安装到/hello下,为了测试这个应用,我们可以这么做,在第一个文件框中输入“/hello”(作为访问时的 path),在第二个文本框中输入“file:/home/user/hello”(作为Config URL)。
      
       Manager application还允许你停止、重新启动、移除以及重新部署一个web应用。停止一个应用使其无法被访问,当有用户尝试访问这个被停止的应用时,将看到一个503的错误??“503 - This application is not currently available”。
      
      移除一个web应用,只是指从Tomcat的运行拷贝中删除了该应用,如果你重新启动Tomcat,被删除的应用将再次出现(也就是说,移除并不是指从硬盘上删除)。
      
      3、部署一个web应用
      
      有两个办法可以在系统中部署web服务。
      
      1. 拷贝你的WAR文件或者你的web应用文件夹(包括该web的所有内容)到$CATALINA_BASE/webapps目录下。
      
      2. 为你的web服务建立一个只包括context内容的XML片断文件,并把该文件放到$CATALINA_BASE/webapps目录下。这个web应用本身可以存储在硬盘上的任何地方。
      
      如果你有一个WAR文件,你若想部署它,则只需要把该文件简单的拷贝到CATALINA_BASE/webapps目录下即可,文件必须以“.war” 作为扩展名。一旦Tomcat监听到这个文件,它将(缺省的)解开该文件包作为一个子目录,并以WAR文件的文件名作为子目录的名字。
      
      接下来,Tomcat将在内存中建立一个context,就好象你在server.xml文件里建立一样。当然,其他必需的内容,将从server.xml中的DefaultContext获得。
      
      部署web应用的另一种方式是写一个Context XML片断文件,然后把该文件拷贝到CATALINA_BASE/webapps目录下。一个Context片断并非一个完整的XML文件,而只是一个context元素,以及对该应用的相应描述。
      
      这种片断文件就像是从server.xml中切取出来的context元素一样,所以这种片断被命名为“context片断”。
      
      举个例子,如果我们想部署一个名叫MyWebApp.war的应用,该应用使用realm作为访问控制方式,我们可以使用下面这个片断:
      
      <!--
      Context fragment for deploying MyWebApp.war
      -->
      <Context path="/demo"
      docBase="webapps/MyWebApp.war"
      debug="0" privileged="true">
      <Realm className=
      "org.apache.catalina.realm.UserDatabaseRealm”

    resourceName="UserDatabase"/>
      </Context>
      
      把该片断命名为“MyWebApp.xml”,然后拷贝到CATALINA_BASE/webapps目录下。
      
      这种context片断提供了一种便利的方法来部署web应用,你不需要编辑server.xml,除非你想改变缺省的部署特性,安装一个新的web应用时不需要重启动Tomcat。
      
      4、配置虚拟主机(Virtual Hosts)
      
      关于server.xml中“Host”这个元素,只有在你设置虚拟主机的才需要修改。虚拟主机是一种在一个web服务器上服务多个域名的机制,对每个域名而言,都好象独享了整个主机。实际上,大多数的小型商务网站都是采用虚拟主机实现的,这主要是因为虚拟主机能直接连接到Internet并提供相应的带宽,以保障合理的访问响应速度,另外虚拟主机还能提供一个稳定的固定IP。
      
      基于名字的虚拟主机可以被建立在任何web服务器上,建立的方法就是通过在域名服务器(DNS)上建立IP地址的别名,并且告诉web服务器把去往不同域名的请求分发到相应的网页目录。因为这篇文章主要是讲Tomcat,我们不准备介绍在各种操作系统上设置DNS的方法,如果你在这方面需要帮助,请参考《DNS and Bind》一书,作者是Paul Albitz and Cricket Liu (O'Reilly)。为了示范方便,我将使用一个静态的主机文件,因为这是测试别名最简单的方法。
      
      在Tomcat中使用虚拟主机,你需要设置DNS或主机数据。为了测试,为本地IP设置一个IP别名就足够了,接下来,你需要在server.xml中添加几行内容,如下:
      
      <Server port="8005"
      shutdown="SHUTDOWN" debug="0">
      <Service name="Tomcat-Standalone">
      <Connector className=
      "org.apache.coyote.tomcat4.CoyoteConnector"
      port="8080"
      minProcessors="5" maxProcessors="75"
      enableLookups="true"
      redirectPort="8443"/>
      <Connector className=
      "org.apache.coyote.tomcat4.CoyoteConnector"
      port="8443" minProcessors="5"
      maxProcessors="75"
      acceptCount="10" debug="0"
      scheme="https" secure="true"/>
      <Factory className="org.apache.coyote.
      tomcat4.CoyoteServerSocketFactory"
      clientAuth="false" protocol="TLS" />
      </Connector>
      <Engine name="Standalone"
      defaultHost="localhost" debug="0">
      <!-- This Host is the default Host -->
      <Host name="localhost"
      debug="0" appBase="webapps"
      unpackWARs="true" autoDeploy="true">
      <Context path="" docBase="ROOT" debug="0"/>
      <Context path="/orders"
      docBase="/home/ian/orders" debug="0"
      reloadable="true" crossContext="true">
      </Context>
      </Host>
      
      <!-- This Host is the first
      "Virtual Host": http://www.example.com/ -->
      <Host name="www.example.com"
      appBase="/home/example/webapp">
      <Context path="" docBase="."/>
      </Host>
      
      </Engine>
      </Service>
      </Server>
      
      Tomcat的server.xml文件,在初始状态下,只包括一个虚拟主机,但是它容易被扩充到支持多个虚拟主机。在前面的例子中展示的是一个简单的server.xml版本,其中粗体部分就是用于添加一个虚拟主机。每一个Host元素必须包括一个或多个context元素,所包含的context元素中必须有一个是默认的context,这个默认的context的显示路径应该为空(例如,path=””)。
      
      5、配置基础验证(Basic Authentication)
      
      容器管理验证方法控制着当用户访问受保护的web应用资源时,如何进行用户的身份鉴别。当一个web应用使用了Basic Authentication(BASIC参数在web.xml文件中auto-method元素中设置),而有用户访问受保护的web应用时,Tomcat将通过HTTP Basic Authentication方式,弹出一个对话框,要求用户输入用户名和密码。在这种验证方法中,所有密码将被以64位的编码方式在网络上传输。
      
      注意:使用Basic Authentication通过被认为是不安全的,因为它没有强健的加密方法,除非在客户端和服务器端都使用HTTPS或者其他密码加密码方式(比如,在一个虚拟私人网络中)。若没有额外的加密方法,网络管理员将能够截获(或滥用)用户的密码。
      
      但是,如果你是刚开始使用 Tomcat,或者你想在你的web应用中测试一下基于容器的安全管理,Basic Authentication还是非常易于设置和使用的。只需要添加<security-constraint>和<login-config>两个元素到你的web应用的web.xml文件中,并且在CATALINA_BASE/conf/tomcat-users.xml文件中添加适当的<role>和<user>即可,然后重新启动Tomcat。
      
      下面例子中的web.xml摘自一个俱乐部会员网站系统,该系统中只有member目录被保护起来,并使用Basic Authentication进行身份验证。请注意,这种方式将有效的代替Apache web服务器中的.htaccess文件。
      
      <!--
      Define the
      Members-only area,
      by defining
      a "Security Constraint"
      on this Application, and
      mapping it to the
      subdirectory (URL) that we want

    to restrict.
      -->
      <security-constraint>
      <web-resource-collection>
      <web-resource-name>
      Entire Application
      </web-resource-name>
      <url-pattern>/members/*</url-pattern>
      </web-resource-collection>
      <auth-constraint>
      <role-name>member</role-name>
      </auth-constraint>
      </security-constraint>
      <!-- Define the Login
      Configuration for
      this Application -->
      <login-config>
      <auth-method>BASIC</auth-method>
      <realm-name>My Club
      Members-only Area</realm-name>
      </login-config>
      
      6、配置单点登录(Single Sign-On)
      
      一旦你设置了realm和验证的方法,你就需要进行实际的用户登录处理。一般说来,对用户而言登录系统是一件很麻烦的事情,你必须尽量减少用户登录验证的次数。作为缺省的情况,当用户第一次请求受保护的资源时,每一个web应用都会要求用户登录。
      
      如果你运行了多个web应用,并且每个应用都需要进行单独的用户验证,那这看起来就有点像你在与你的用户搏斗。用户们不知道怎样才能把多个分离的应用整合成一个单独的系统,所有他们也就不知道他们需要访问多少个不同的应用,只是很迷惑,为什么总要不停的登录。
      
      Tomcat 4的“single sign-on”特性允许用户在访问同一虚拟主机下所有web应用时,只需登录一次。为了使用这个功能,你只需要在Host上添加一个SingleSignOn Valve元素即可,如下所示:
      
      <Valve className=
      "org.apache.catalina.
      authenticator.SingleSignOn"
      debug="0"/>
      
      在Tomcat初始安装后,server.xml的注释里面包括SingleSignOn Valve配置的例子,你只需要去掉注释,即可使用。那么,任何用户只要登录过一个应用,则对于同一虚拟主机下的所有应用同样有效。使用single sign-on valve有一些重要的限制:
      
      1> value必须被配置和嵌套在相同的Host元素里,并且所有需要进行单点验证的web应用(必须通过context元素定义)都位于该Host下。
      
      2> 包括共享用户信息的realm必须被设置在同一级Host中或者嵌套之外。
      
      3> 不能被context中的realm覆盖。
      
      4> 使用单点登录的web应用最好使用一个Tomcat的内置的验证方式(被定义在web.xml中的<auth-method>中),这比自定义的验证方式强,Tomcat内置的的验证方式包括basic、digest、form和client-cert。
      
      5> 如果你使用单点登录,还希望集成一个第三方的web应用到你的网站中来,并且这个新的web应用使用它自己的验证方式,而不使用容器管理安全,那你基本上就没招了。你的用户每次登录原来所有应用时需要登录一次,并且在请求新的第三方应用时还得再登录一次。
      
      当然,如果你拥有这个第三方web应用的源码,而你又是一个程序员,你可以修改它,但那恐怕也不容易做。
      
      6> 单点登录需要使用cookies。
      
      7、配置用户定制目录(Customized User Directores)
      
      一些站点允许个别用户在服务器上发布网页。例如,一所大学的学院可能想给每一位学生一个公共区域,或者是一个ISP希望给一些web空间给他的客户,但这又不是虚拟主机。在这种情况下,一个典型的方法就是在用户名前面加一个特殊字符(~),作为每位用户的网站,比如:
      
      http://www.cs.myuniversity.edu/~username
      http://members.mybigisp.com/~username
      
      Tomcat提供两种方法在主机上映射这些个人网站,主要使用一对特殊的Listener元素。Listener的className属性应该是 org.apache.catalina.startup.UserConfig,userClass属性应该是几个映射类之一。
      
      如果你的系统是Unix,它将有一个标准的/etc/passwd文件,该文件中的帐号能够被运行中的Tomcat很容易的读取,该文件指定了用户的主目录,使用PasswdUserDatabase 映射类。
      
      <Listener className=
      "org.apache.catalina.startup.UserConfig"
      directoryName="public_html"
      userClass="org.apache.catalina.
      startup.PasswdUserDatabase"/>
      
      web文件需要放置在像/home/users/ian/public_html或者/users/jbrittain/public_html一样的目录下面。当然你也可以改变public_html 到其他任何子目录下。
      
      实际上,这个用户目录根本不一定需要位于用户主目录下里面。如果你没有一个密码文件,但你又想把一个用户名映射到公共的像/home一样目录的子目录里面,则可以使用HomesUserDatabase类。
      
      <Listener className=
      "org.apache.catalina.startup.UserConfig"
      directoryName="public_html"
      homeBase="/home"
      userClass="org.apache.catalina.
      startup.HomesUserDatabase"/>
      
      这样一来,web文件就可以位于像/home/ian/public_html或者/home/jasonb/public_html一样的目录下。这种形式对Windows而言更加有利,你可以使用一个像c:home这样的目录。
      
      这些Listener元素,如果出现,则必须在Host元素里面,而不能在context元素里面,因为它们都用应用于Host本身。
      
      8、在Tomcat中使用CGI脚本
      
      Tomcat主要是作为Servlet/JSP容器,但它也有许多传统web服务器的性能。支持通用网关接口(Common Gateway Interface,即CGI)就是其中之一,CGI提供一组方法在响应浏览器请求时运行一些扩展程序。
      
      CGI之所以被称为通用,是因为它能在大多数程序或脚本中被调用,包括:Perl,Python,awk,Unix shell scrīpting等,甚至包括Java。

    当然,你大概不会把一个Java应用程序当作CGI来运行,毕竟这样太过原始。一般而言,开发Servlet总要比CGI具有更好的效率,因为当用户点击一个链接或一个按钮时,你不需要从操作系统层开始进行处理。
      
      Tomcat包括一个可选的CGI Servlet,允许你运行遗留下来的CGI脚本。
      
      为了使Tomcat能够运行CGI,你必须做如下几件事:
      
      1. 把servlets-cgi.renametojar (在CATALINA_HOME/server/lib/目录下)改名为servlets-cgi.jar。处理CGI的servlet应该位于Tomcat的CLASSPATH下。
      
      2. 在Tomcat的CATALINA_BASE/conf/web.xml 文件中,把关于<servlet-name> CGI的那段的注释去掉(默认情况下,该段位于第241行)。
      
      3. 同样,在Tomcat的CATALINA_BASE/conf/web.xml文件中,把关于对CGI进行映射的那段的注释去掉(默认情况下,该段位于第299行)。注意,这段内容指定了HTML链接到CGI脚本的访问方式。
      
      4. 你可以把CGI脚本放置在WEB-INF/cgi 目录下(注意,WEB-INF是一个安全的地方,你可以把一些不想被用户看见或基于安全考虑不想暴露的文件放在此处),或者你也可以把CGI脚本放置在 context下的其他目录下,并为CGI Servlet调整cgiPathPrefix初始化参数。这就指定的CGI Servlet的实际位置,且不能与上一步指定的URL重名。
      
      5. 重新启动Tomcat,你的CGI就可以运行了。
      
      在Tomcat中,CGI程序缺省放置在WEB-INF/cgi目录下,正如前面所提示的那样,WEB-INF目录受保护的,通过客户端的浏览器无法窥探到其中内容,所以对于放置含有密码或其他敏感信息的CGI脚本而言,这是一个非常好的地方。
      
      为了兼容其他服务器,尽管你也可以把CGI脚本保存在传统的/cgi-bin目录,但要知道,在这些目录中的文件有可能被网上好奇的冲浪者看到。另外,在Unix中,请确定运行Tomcat的用户有执行CGI脚本的权限。
      
      9、改变Tomcat中的JSP编译器(JSP Compiler)
      
      在Tomcat 4.1(或更高版本,大概),JSP的编译由包含在Tomcat里面的Ant程序控制器直接执行。这听起来有一点点奇怪,但这正是Ant有意为之的一部分,有一个API文档指导开发者在没有启动一个新的JVM的情况下,使用Ant。
      
      这是使用Ant进行Java开发的一大优势。另外,这也意味着你现在能够在Ant中使用任何javac支持的编译方式,这里有一个关于Apache Ant使用手册的javac page列表。
      
      使用起来是容易的,因为你只需要在<init-param> 元素中定义一个名字叫“compiler”,并且在value中有一个支持编译的编译器名字,示例如下:
      
      <servlet>
      <servlet-name>jsp</servlet-name>
      <servlet-class>
      org.apache.jasper.servlet.JspServlet
      </servlet-class>
      <init-param>
      <param-name>logVerbosityLevel
      </param-name>
      <param-value>WARNING</param-value>
      </init-param>
      <init-param>
      <param-name>compiler</param-name>
      <param-value>jikes</param-value>
      </init-param>
      <load-on-startup>3</load-on-startup>
      </servlet>
      
      当然,给出的编译器必须已经安装在你的系统中,并且CLASSPATH可能需要设置,那处决于你选择的是何种编译器。
      
      10、限制特定主机访问(Restricting Access to Specific Hosts)
      
      有时,你可能想限制对Tomcat web应用的访问,比如,你希望只有你指定的主机或IP地址可以访问你的应用。这样一来,就只有那些指定的的客户端可以访问服务的内容了。为了实现这种效果,Tomcat提供了两个参数供你配置:RemoteHostValve 和RemoteAddrValve。
      
      通过配置这两个参数,可以让你过滤来自请求的主机或IP地址,并允许或拒绝哪些主机/IP。与之类似的,在Apache的httpd文件里有对每个目录的允许/拒绝指定。例如你可以把Admin Web application设置成只允许本地访问,设置如下:
      
      <Context path=
      "/path/to/secret_files" ...>
      <Valve className="org.apache.
      catalina.valves.RemoteAddrValve"
      allow="127.0.0.1" deny=""/>
      </Context>
      
      如果没有给出允许主机的指定,那么与拒绝主机匹配的主机就会被拒绝,除此之外的都是允许的。与之类似,如果没有给出拒绝主机的指定,那么与允许主机匹配的主机就会被允许,除此之外的都是拒绝的。

  • 监控Tomcat服务器性能

    2008-10-28 23:21:46

    在进行性能测试时,一般都需要对应用服务器进行监控,监控的指标包括应用服务器的JVM使用状况、可用连接数、队列长度等信息。商业的应用服务器如WebLogic、WebSphere等都提供了Console对这些指标进行监控,在性能测试时可以很容易观察这些指标的情况。

      Tomcat作为在国内得到广泛应用的J2EE服务器,在不少项目中都得到了使用。Tomcat小巧灵活、配置简单,非常适合小的WEB应用使用。但在对使用Tomcat的应用系统进行性能测试时,最头疼的问题就是不能获得应用服务器的相关性能指标数据

      其实,从Tomcat 5.0开始,Tomcat就已经为自己提供了一个用于监控应用服务器性能指标的servelet —— status servelet。安装完Tomcat 5之后,通过访问http://yourhost:port/manager/status就可以获得当时的应用服务器监控数据。

      当然,为了安全起见,Tomcat 5在缺省安装时是不允许用户直接访问http://yourhost:port/manager/status的,访问的时候会给出一个403(forbidden)的错误信息。在Tomcat的Manual里说明了允许用户访问的方法:

       1. 转到Tomcat的安装目录下;
       2. 修改conf/tomcat-users.xml文件,在其中加入一行  <user username="servermon" password="passwd" roles="manager"/>

      这样就可以在访问http://yourhost:port/manager/status时给出 servermon 的用户名与口令,查看到应用服务器的相关性能指标数据。

Open Toolbar