发布新日志

  • 创建和发布web应用--tomcat

    2009-07-08 14:51:24

    本章介绍如何在Tomcat上创建和发布Web应用。这里首先讲解Tomcat的目录结构以
    及Web应用的目录结构,接着介绍如何将HTML、Servlet、JSP和Tag Library部署到Web
    应用中,然后介绍把整个Web 应用打包并发布的方法,最后介绍如何在Tomcat 上配置虚
    拟主机。
    本章侧重于讨论Web 应用的结构和发布方法,所以没有对本章的Servlet 和JSP 的例
    子进行详细解释,关于Servlet和JSP的技术可以分别参考第3 章和第4 章的内容。
    2.1 Tomcat 的目录结构
    在 Tomcat上发布Web应用之前,首先要了解Tomcat 的目录结构。Tomcat的目录结构
    参见表2-1,这些目录都是<CATALINA_HOME>的子目录。
    表2-1 Tomcat的目录结构
     目录 描述
     /bin  存放在Windows平台以及Linux平台上启动和关闭Tomcat的脚本文件
     /conf  存放Tomcat 服务器的各种配置文件,其中最重要的配置文件是server.xml
     /server  包含3 个子目录: classes、lib和webapps
     /server/lib  存放Tomcat 服务器所需的各种JAR 文件
    /server/webapps
    存放Tomcat 自带的两个Web应用: admin应用和manager应用
     /common/lib  存放Tomcat 服务器以及所有Web应用都可以访问的JAR 文件
     /shared/lib  存放所有Web应用都可以访问的JAR 文件
     /logs  存放Tomcat 的日志文件
     /webapps  当发布Web应用时,默认情况下把Web应用文件放于此目录下
     /work  Tomcat 把由JSP 生成的Servlet 放于此目录下

    从表2-1 可以看出,在/server/lib 目录、/common/lib 和/shared/lib 目录下都可以放JAR
    文件,它们的区别在于:
    l 在/server/lib 目录下的JAR文件只可被Tomcat服务器访问
    l 在/shared/lib 目录下的JAR 文件可以被所有的Web 应用访问,但不能被Tomcat
    服务器访问
    l 在/common/lib 目录下的JAR文件可以被Tomcat服务器和所有Web应用访问
    此外,对于下面将要介绍的Java Web应用,在它的WEB-INF目录下,也可以建立lib
    子目录,在lib 子目录下可以放各种JAR文件,这些JAR文件只能被当前Web 应用访问。
    (在以上提到的lib 目录下都只接受JAR文件,如果类压缩文件为ZIP文
    件,应该将它展开,重新打包为JAR文件再拷贝到lib 目录中。如果直接将
    ZIP文件拷贝到lib 目录,则会发现Tomcat服务器仍然找不到相关的类。打
    包命令参见2.2.8 节。)
    2.2 创建和发布 Web 应用
    Java Web应用由一组静态HTML页、Servlet、JSP和其他相关的class组成。每种组件
    在Web应用中都有固定的存放目录。Web应用的配置信息存放在web.xml文件中。在发布
    某些组件(如Servlet)时,必须在web.xml文件中添加相应的配置信息。
    2.2.1 Web应用的目录结构
    Web应用具有固定的目录结构,假定开发一个名为helloapp的Web应用。首先,应该
    在<CATALINA_HOME>/webapps目录下创建这个Web应用的目录结构,参见表2-2。
    表2-2 Web应用的目录结构
     目录 描述
     /helloapp  Web应用的根目录,所有的JSP 和HTML 文件都存放于此目录
     /helloapp/WEB-INF  存放Web应用的发布描述文件web.xml
     /helloapp/WEB-INF/classes  存放各种class文件,Servlet 类文件也放于此目录下
     helloapp/WEB-INF/lib/  存放Web应用所需的各种JAR文件。例如,在这个目录下,可以存放JDBC
    驱动程序的JAR 文件

    从表2-2 中,我们看到在classes 以及lib 子目录下,都可以存放Java 类文件。在运行
    过程中,Tomcat 的类装载器先装载classes 目录下的类,再装载lib 目录下的类。因此,如
    果两个目录下存在同名的类,classes目录下的类具有优先权。
    本章介绍的 helloapp 应用的目录结构如图2-1 所示,helloapp 应用在Windows 资源管
    理器中的展开如图2-2所示。
    在helloapp应用中创建了如下组件:
    l  HTML组件:index.htm
    l  JSP组件:login.jsp和hello.jsp
    l  Servlet组件:DispatcherServlet
    这些组件之间的链接关系为:
    index.htm→login.jsp→DispatcherServlet→hello.jsp






    2.2.2 web.xml文件
    Java Web 应用通过一个基于XML 的发布描述符文件来配置其发布信息,这个文件名
    为web.xml,它存放于WEB-INF子目录下。在附录B中将详细介绍web.xml的配置方法,
    在附录C中将介绍XML的基本知识。在web.xml文件中可包含如下配置信息:
    l  Servlet的定义
    l  Servlet的初始化参数
    l  Servlet以及JSP的映射
    l  安全域配置参数
    l  welcome文件清单
    l 资源引用
    l  环境变量的定义
    现在,创建一个默认的web.xml文件,并把这个文件放到WEB-INF目录中。
    <?xml version="1.0" encoding="ISO-8859-1"?>
    <!DOCTYPE web-app PUBLIC
    '-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN'
    'http://java.sun.com/j2ee/dtds/web-app_2_3.dtd'>
    <web-app>
    </web-app>
    以上web.xml 文件的第一行指定了XML 的版本和字符编码,第二行DOCTYPE 指定
    文档类型,接下来声明了一个<web-app>元素,所有关于Web 应用的配置元素都将加入到
    这个<web-app>元素中。
    2.2.3 在server.xml中加入<Context>元素
    <Context>元素是<CATLINA_HOME>/conf/server.xml 中使用最频繁的元素,它代表了
    运行在<Host>上的单个Web 应用。一个<Host>中可以有多个<Context>元素。每个Web 应
    用必须有惟一的URL路径,这个URL路径在<Context>元素的path属性中设定。
    例如,在名为“localhost”的<Host>元素中加入如下<Context>元素:
    <!-- Define the default virtual host -->
    <Host name="localhost" debug="0" appBase="webapps"
    unpackWARs="true" autoDeploy="true">
    ……
    ……
    <Context path="/helloapp" docBase="helloapp" debug="0"
    reloadable="true"/>
    </Host>
    Context元素的各个属性的说明参见表2-3。
    表2-3 Context元素的属性
     属性 描述
     path  指定访问该Web应用的URL 入口
     docBase  指定Web 应用的文件路径,可以给定绝对路径,也可以给定相对于Host 的appBase 属性的相对路径
    (关于Host 的appBase 属性参见2.3 节)。如果Web应用采用开放目录结构,则指定Web应用的根目录;
    如果Web应用是个WAR 文件,则指定WAR 文件的路径
    reloadable
    如果这个属性设为true,Tomcat 服务器在运行状态下会监视在WEB-INF/classes 和WEB-INF/lib 目录
    下class文件的改动。如果监测到有class文件被更新,服务器会自动重新加载Web应用

    (在开发阶段,将reloadable属性设为true,有助于调试Servlet和其他的
    class 文件。但是由于这一功能会加重服务器的运行负荷,因此建议在Web
    应用的产品发布阶段,将这个属性设为false。)

    2.2.4 部署HTML文件
    在 helloapp 目录下加入index.htm 文件,这个文件仅仅用来显示一串带链接的字符
    “Welcome to HelloApp”, 它链接到login.jsp文件。以下是index.htm文件的代码:
    <html>
      <head>
        <title>helloapp</title>
      </head>
      <body >
        <p><font size="7">Welcome to HelloApp</font></p>
        <p><a href="login.jsp?language=English">English version </a>
      </body>
    </html>
    访问index.htm 的URL 为http://localhost:8080/helloapp/index.htm,该页面的显示结果
    如图2-3所示。
    图2-3 :

    2.2.5 部署JSP
    接下来,创建两个JSP文件,其中一个是login.jsp(参见例程2-1),它显示登录页面,
    要求输入用户名和口令,这个页面链接到一个名为DispatcherServlet的Servlet。还有一个
    JSP文件是hello.jsp(参见例程2-2),这个JSP被DispatcherServlet调用,显示Hello页面。
    JSP 的语法将在第4 章详细讨论,本节侧重于介绍JSP 的发布过程。这两个JSP 文件都应
    放在helloapp目录下。
    例程2-1 login.jsp:
    <html>
         <head>
            <title>helloapp</title>
         </head>
         <body >
            <br>
            <form. name="loginForm" method="post" action="dispatcher">
               <table>
                  <tr>
                      <td><div align="right">User Name:</div></td>
                      <td> <input type="text" name="username"></td>
                  </tr>
                  <tr>
                      <td><div align="right">Password:</div></td>
                      <td><input type="password" name="password"></td>
                  </tr>
                  <tr>
                      <td></td>
                      <td><input type="Submit" name="Submit" value="Submit"></td>
                  </tr>
                </table>
              </form>
            </body>
    </html

    例程2-2 hello.jsp:
    <html>
       <head>
          <title>helloapp</title>
       </head>
       <body>
          <b>Welcome: <%= request.getAttribute("USER") %></b>
       </body>
    </html>
    login.jsp 中生成了一个loginForm表单,它有两个字段:username 和passoword。访问
    login.jsp的URL为http://localhost:8080/helloapp/login.jsp,它生成的页面如图2-4所示。
    图2-4 login.jsp网页

    2.2.6 部署Servlet
    下面,创建一个Servlet 文件,名为DispatcherServlet.java(参见例程2-3),它调用
    HttpServletRequest对象的getParameter 方法读取客户提交的loginForm表单数据,获取用户
    名和口令,然后将用户名和口令保存在HttpServletRequest对象的属性中,再把请求转发给
    hello.jsp。
    例程2-3 DispatcherServlet.java
    package mypack;
    import javax.servlet.*;
    import javax.servlet.http.*;
    import java.io.*;
    import java.util.*;
    public class DispatcherServlet extends HttpServlet {
    private String target = "/hello.jsp";
    public void init(ServletConfig config)
    throws ServletException {
    super.init(config);
    }
    public void doGet(HttpServletRequest request,
    HttpServletResponse response)
    throws ServletException, IOException {
    // If it is a get request forward to doPost()
    doPost(request, response);
    }
    public void doPost(HttpServletRequest request,
    HttpServletResponse response)
    throws ServletException, IOException {
    // Get the username from the request
    String username = request.getParameter("username");
    // Get the password from the request
    String password = request.getParameter("password");
    // Add the user to the request
    request.setAttribute("USER", username);
    request.setAttribute("PASSWORD", password);
    // Forward the request to the target named
    ServletContext context = getServletContext();
    System.out.println("Redirecting to " + target);
    RequestDispatcher dispatcher =
    context.getRequestDispatcher(target);
    dispatcher.forward(request, response);
    }
    public void destroy() {
    }
    }

    编译并发布DispatcherServlet的步骤如下。
    (1)编译DispatcherServlet.java。编译时,需要将Java Servlet API 的JAR 文件
    (servlet-api.jar)设置为classpath,servlet-api.jar 文件位于<CATALINA_HOME>/common/lib
    目录下。
    ( 2 ) 把编译出来的class 文件拷贝到/helloapp/WEB_INF/classes 目录下。
    DispatcherServlet.class的存放位置为/helloapp/WEB_INF/classes/mypack/DispatcherServlet。
    在本例中,声明将DispatcherServlet 类放在包mypack 下,所以应该在
    /WEB_INF/classes 目录下先创建子目录/mypack,然后在子目录下放
    DispatcherServlet.class文件。
    (3)接下来在web.xml中为DispatcherServlet类加上<servlet>和<servlet-mapping>元素。
    <web-app>
    <servlet>
    <servlet-name>dispatcher</servlet-name>
    <servlet-class>mypack.DispatcherServlet</servlet-class>
    </servlet>
    <servlet-mapping>
    <servlet-name>dispatcher</servlet-name>
    <url-pattern>/dispatcher</url-pattern>
    </servlet-mapping>
    </web-app>
    <servlet>元素的属性描述参见表2-4。
    在本例配置中,没有为DispatcherServlet设置load-on-startup属性,因此当Web应用启
    动时,Servlet 容器不会加载这个Servlet,只有当Web 客户首次访问这个Servlet 时才加载
    它。
    表2-4 <servlet>元素的属性:
    属性
    说明
     <servlet-name>  定义Servlet 的名字
     <servlet-class>  指定实现这个Servlet 的类
    <init-param>
    定义Servlet 的初始化参数(包括参数名和参数值),一个<servlet>元素中可以有
    多个<init-param>
    <load-on-startup>
    指定当Web 应用启动时,装载Servlet 的次序。当这个值为正数或零,Servlet 容
    器先加载数值小的Servlet,再依次加载其他数值大的Servlet。如果这个值为负数或
    者没有设定,那么Servlet 容器将在Web客户首次访问这个Servlet 时加载它

    <servlet-mapping>元素用来指定<servlet-name>和<url-pattern>映射。<url-pattern>是指访
    问Servlet的相对URL路径。
    根据以上<url-pattern>属性,访问DispatcherServlet 的URL 为http://localhost:8080/
    helloapp/dispatcher,DispatcherServlet接受到客户请求后,再把请求转发给hello.jsp,hello.jsp
    生成的页面如图2-5所示。
    图2-5 DispatcherServlet调用hello.jsp生成的网页
    2.2.7 部署JSP Tag Library
    最后,在Web应用中加入Tag Library(标签库)。Tag Library向用户提供了自定义JSP
    标签的功能。我们将定义一个名为mytaglib 的标签库,它包含了一个简单的hello标签,这
    个标签能够将JSP页面中所有的<mm:hello/>解析为字符串“hello”。
    以下是创建和发布mytaglib 标签库的步骤。
    (1)编写用于处理hello 标签的类HelloTag.java,例程2-4 列出了HelloTag.java 的源
    代码。
    例程2-4 HelloTag.java
    package mypack;
    import javax.servlet.jsp.JspException;
    import javax.servlet.jsp.JspTagException;
    import javax.servlet.jsp.tagext.TagSupport;
    public class HelloTag extends TagSupport
    {
    public void HelloTag() { }
    // Method called when the closing hello tag is encountered
    public int doEndTag() throws JspException {
    try {
    // We use the pageContext to get a Writer
    // We then print the text string Hello
    pageContext.getOut().print("Hello");
    }
    catch (Exception e) {
    throw new JspTagException(e.getMessage());
    }
    // We want to return SKIP_BODY because this Tag does not support
    // a Tag Body
    return SKIP_BODY;
    }
    public void release() {
    // Call the parent's release to release any resources
    // used by the parent tag.
    // This is just good practice for when you start creating
    // hierarchies of tags.
    super.release();
    }
    }

    编译HelloTag.java 时,需要将jsp-api.jar 文件添加到classpath中,这个JAR文件位于
    <CATALINA_HOME>/common/lib 目录下。编译生成的HelloTag.class 存放位置为
    /WEB-INF/classes/mypack/HelloTag.class。
    (2)创建Tag Library的描述文件mytaglib.tld文件,在这个文件中定义mytaglib 标签
    库和hello标签。这个文件存放位置为/WEB-INF/mytaglib.tld。例程2-5 列出了mytaglib.tld
    的源代码。
    例程2-5 mytaglib.tld
    <?xml version="1.0" encoding="ISO-8859-1" ?>
    <!DOCTYPE taglib
    PUBLIC "-//Sun Microsystems, Inc.//DTD JSP Tag Library 1.1//EN"
    "http://java.sun.com/j2ee/dtds/web-jsptaglibrary_1_1.dtd">
    <!-- a tag library descriptor -->
    <taglib>
    <tlibversion>1.0</tlibversion>
    <jspversion>1.1</jspversion>
    <shortname>mytaglib</shortname>
    <uri>/mytaglib</uri>
    <tag>
    <name>hello</name>
    <tagclass>mypack.HelloTag</tagclass>
    <bodycontent>empty</bodycontent>
    <info>Just Says Hello</info>
    </tag>
    </taglib>
    (3)在web.xml文件中加入<taglib>元素,例程2-6列出了修改后的web.xml文件。
    例程2-6 加入<taglib>元素的web.xml
    <?xml version="1.0" encoding="ISO-8859-1"?>
    <!DOCTYPE web-app PUBLIC
    '-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN'
    'http://java.sun.com/j2ee/dtds/web-app_2_3.dtd'>
    <web-app>
    <servlet>
    <servlet-name>dispatcher</servlet-name>
    <servlet-class>mypack.DispatcherServlet</servlet-class>
    </servlet>
    <servlet-mapping>
    <servlet-name>dispatcher</servlet-name>
    <url-pattern>/dispatcher</url-pattern>
    </servlet-mapping>
    <taglib>
    <taglib-uri>/mytaglib</taglib-uri>
    <taglib-location>/WEB-INF/mytaglib.tld</taglib-location>
    </taglib>
    </web-app>
    <taglib>中包含两个属性<taglib-uri>和<taglib-location>。其中<taglib-uri>指定Tag
    Library标示符;<taglib-location>指定Tag Library的描述文件(TLD)的位置。
    (4)在hello.jsp文件中加入hello标签。首先,在hello.jsp中加入引用mytaglib 的taglib
    指令:
    <%@ taglib uri="/mytaglib" prefix="mm" %>
    以上taglib 指令中,prefix 用来指定引用mytaglib标签库时的前缀,修改后的hello.jsp
    文件参见例程2-7。
    例程2-7 加入Tag标签的hello.jsp
    <%@ taglib uri="/mytaglib" prefix="mm" %>
    <html>
    <head>
    <title>helloapp</title>
    </head>
    <b><mm:hello/> : <%= request.getAttribute("USER") %></b>
    </body>
    </html>
    hello.jsp 修改后,再依次访问index.htm→login.jsp→DispatcherServlet→hello.jsp,最后
    生成的网页如图2-6所示。
    图2-6 带hello标签的hello.jsp生成的网页
    2.2.8 创建并发布WAR文件
    Tomcat既可以运行采用开放式目录结构的Web应用,也可以运行WAR文件。在本书
    配套光盘的sourcecode/chapter2/helloapp目录下提供了所有源文件,只要把整个helloapp目
    录拷贝到<CATALINA_HOME>/webapps目录下,即可运行开放式目录结构的helloapp应用。
    在 Web应用的开发阶段,为了便于调试,通常采用开放式的目录结构来发布Web应用,
    这样可以方便地更新或替换文件。如果开发完毕,进入产品发布阶段,应该将整个Web 应
    用打包为WAR文件,再进行发布。
    在本例中,按如下步骤发布helloapp。
    步骤:
    (1)进入helloapp应用的根目录<CATALINA_HOME>/webapps/helloapp。
    (2)把整个Web应用打包为helloapp.war 文件,命令如下:
    jar cvf helloapp.war *.*
    (在 JDK 的bin 目录下提供了打包程序jar.exe。如果要展开helloapp.war
    文件,命令为: jar xvf helloapp.war。)
    (3)把helloapp.war 文件拷贝到<CATALINA_HOME>/webapps目录下。
    (4)删除原先的helloapp目录。
    (5)启动Tomcat服务器。
    Tomcat 服务器启动时,会把webapps 目录下的所有WAR 文件自动展开为开放式的目
    录结构。所以服务器启动后,会发现服务器把helloapp.war 展开到<CATALINA_HOME>
    /webapps/helloapp目录中。
    2.3 配置虚拟主机
    在 Tomcat 的配置文件server.xml 中,Host 元素代表虚拟主机,在同一个Engine 元素
    下可以配置多个虚拟主机。例如,有两个公司的Web 应用都发布在同一个Tomcat 服务器
    上,可以为每家公司分别创建一个虚拟主机,它们的虚拟主机名分别为:
    www.mycompany1.com
    www.mycompany2.com
    这样当Web客户访问以上两个Web应用时,就好像这两个应用分别拥有各自的主机。
    此外,还可以为虚拟主机建立别名,例如,如果希望Web客户访问www.mycompany1.com
    或mycompany1.com都能连接到同一个Web,那么可以把mycompany1.com 作为虚拟主机
    的别名来处理。
    下面讲解如何配置www.mycompany1.com虚拟主机。
    步骤:
    (1)打开<CATALINA_HOME>/conf/server.xml 文件,会发现在<Engine>元素中已经
    有一个名为localhost 的<Host >元素,可以在它的后面(即</Host>后面)加入如下<Host>
    元素:
    <Host name="www.mycompany1.com" debug="0" appBase="C:\mycompany1"
    unpackWARs="true" autoDeploy="true">
    <alias>mycompany1.com</alias>
    <alias>mycompany1</alias>
    <Context path="/helloapp" docBase="helloapp" debug="0"
    reloadable="true" />
    </Host>
    (以上配置代码位于本书配套光盘的sourcecode/chapter2/virtualhost-configure.xml 文件
    中。)
    <Host>元素的属性描述参见表2-5。
    表2-5 <Host>元素的属性
     属性 描述
     name  指定虚拟主机的名字
     debug  指定日志级别
    appBase
    指定虚拟主机的目录,可以指定绝对目录,也可以指定相对于<CATALINA_HOME>的相对
    目录。如果此项没有设定,默认值为<CATALINA_HOME>/webapps
    unpackWARs
    如果此项设为true,表示将把Web 应用的WAR 文件先展开为开放目录结构后再运行。如
    果设为false,则直接运行WAR 文件
    autoDeploy
    如果此项设为true,表示当Tomcat 服务器处于运行状态时,能够监测appBase 下的文件,
    如果有新的Web应用加入进来,则会自动发布这个Web应用
    alias
    指定虚拟主机的别名,可以指定多个别名
    deployOnStartup
    如果此项设为true,则表示Tomcat 服务器启动时会自动发布appBase 目录下所有的Web应
    用。如果Web应用在server.xml 中没有相应的<Context>元素,则将采用默认的Context 配置。
    deployOnStartup的默认值为true

    在<Host>的deployOnStartup 属性为true 的情况下,即使你没有在server.xml 中为
    helloapp应用加入<Context>元素,Tomcat服务器也可以自动发布和运行helloapp应用。在
    这种情况下,Tomcat使用默认的DefaultContext。关于DefaultContext的知识可以参考Tomcat
    文档:
    <CATALINA_HOME>/webapps/tomcat-docs/config/defaultcontext.html
    (2)把helloapp 应用(helloapp.war 文件或者是整个helloapp 目录)拷贝到appBase
    属性指定的目录C:\mycompany1 下。
    (3)为了使以上配置的虚拟主机生效,必须在DNS 服务器中注册以上的虚拟主机名
    和别名,使它们的IP地址都指向Tomcat服务器所在的机器。必须注册以下名字:
    www.mycompany1.com
    mycompany1.com
    mycompany1
    (4)重启Tomcat服务器,然后通过浏览器访问:
    http://www.mycompany1.com/helloapp/index.htm
    如果返回正常的页面就说明配置成功。还可以通过虚拟机的别名来访问helloapp应用:
    http://mycompany1.com/helloapp/index.htm
    http://mycompany1/helloapp/index.htm

    2.4 小 结
    本章通过helloapp Web 应用例子,介绍了在Tomcat 上创建和发布Web 应用的步骤。
    通过本章内容,读者可以学会创建Web应用的目录结构,创建web.xml文件,并且能够把
    HTML、Servlet、JSP和Tag Library部署到Web应用中。此外,读者还可以掌握将整个Web
    应用打包并发布的方法。本章还介绍了配置虚拟主机的方法。
    为了便于读者编译源程序,在本书配套光盘的sourcecode/chapter2 目录下提供了编译
    本章Java 程序的脚本compile.bat,它的内容如下:
    set catalina_home=C:\jakarta-tomcat
    set path=%path%;C:\j2sdk1.4.2\bin
    set currpath=.\
    if "%OS%" == "Windows_NT" set currpath=%~dp0%
    set src=%currpath%helloapp\src
    set dest=%currpath%helloapp\WEB-INF\classes
    set classpath= %catalina_home%\common\lib\servlet-api.jar;
    %catalina_home%\common\lib\jsp-api.jar
    javac -sourcepath %src% -d %dest% %src%\mypack\DispatcherServlet.java
    javac -sourcepath %src% -d %dest% %src%\mypack\HelloTag.java
    运行这个脚本时,只要重新设置以上Tomcat目录和JDK 的目录即可。
    在 javac 命令中,-sourcepath 设定Java 源文件的路径,-d 设定编译生成的类的存放路
    径。javac 命令的-classpath 参数可以设定classpath 路径,如果此项没有设定,将参照环境
    变量classpath的设置。
  • tomcat官方网站

    2009-07-07 17:44:19

    http://tomcat.apache.org/download-60.cgi
  • apache修改端口号

    2009-07-03 10:37:47

    再安装目录中找到apache的配置文件httpd.conf,代开这个文件,找到listen 80代码,把80改为你自己想设置的端口号。 最后要重启apache。

    注意,配置好了以后一定要重启,不然无效!

  • 启动apache的命令

    2009-07-03 10:29:17

    你可以通过命令行开关来控制Apache服务。要启动一个已经安装的Apache服务,可以使用:
    httpd -k start
    要停止一个已经安装的Apache服务,可以使用:
    httpd -k stop

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

    2009-06-26 23:15:05

     
    简介

      Tomcat 服务器是一个免费的开放源代码的Web 应用服务器,目前最新版本是6.0.20(截止到2009-03-20)。
      Tomcat是Apache 软件基金会(Apache Software Foundation)的Jakarta 项目中的一个核心项目,由Apache、Sun 和其他一些公司及个人共同开发而成。由于有了Sun 的参与和支持,最新的Servlet 和JSP 规范总是能在Tomcat 中得到体现,Tomcat 5 支持最新的Servlet 2.4 和JSP 2.0 规范。因为Tomcat 技术先进、性能稳定,而且免费,因而深受Java 爱好者的喜爱并得到了部分软件开发商的认可,成为目前比较流行的Web 应用服务器。
      Tomcat 很受广大程序员的喜欢,因为它运行时占用的系统资源小,扩展性好,支持负载平衡与邮件服务等开发应用系统常用的功能;而且它还在不断的改进和完善中,任何一个感兴趣的程序员都可以更改它或在其中加入新的功能。
      Tomcat 是一个小型的轻量级应用服务器,在中小型系统和并发访问用户不是很多的场合下被普遍使用,是开发和调试JSP 程序的首选。对于一个初学者来说,可以这样认为,当在一台机器上配置好Apache 服务器,可利用它响应对HTML 页面的访问请求。实际上Tomcat 部分是Apache 服务器的扩展,但它是独立运行的,所以当你运行tomcat 时,它实际上作为一个与Apache 独立的进程单独运行的。
      这里的诀窍是,当配置正确时,Apache 为HTML页面服务,而Tomcat 实际上运行JSP 页面和Servlet。另外,Tomcat和IIS、Apache等Web服务器一样,具有处理HTML页面的功能,另外它还是一个Servlet和JSP容器,独立的Servlet容器是Tomcat的默认模式。不过,Tomcat处理静态HTML的能力不如Apache服务器。

     
    最新版本与规范的对照

      Servlet/JSP_ 规范版本 Apache Tomcat 版本
      ---------------------------------------------
      2.5/2.1____ 6.0.18
      2.4/2.0____ 5.5.25
      2.3/1.2____ 4.1.36
      2.2/1.1____ 3.3.2

     
    常用功能的配置方法
      

      1 启动内存参数的配置
      tomcat/bin/catalina.bat 如果是linux 就是 catalina.sh
      在rem 的后面增加如下参数
      set JAVA_OPTS= -Xms256m -Xmx256m -XX:MaxPermSize=64m
      2 修改Tomcat的JDK目录
      打开tomcat/bin/catalina.bat
      在最后一个rem后面增加
      set JAVA_HOME=C:\Program Files\Java\jdk1.6.0
      3 增加虚拟目录
      /tomcat/conf/server.xml
      第一行是以前默认存在的,第二行是新增的
      <Context path="" docBase="ROOT" debug="0" reloadable="true"></Context>
      <Context path="/jsp/a" reloadable="true" docBase="E:\workplace\www.java2000.net\WebContent" />
      4 GET方式URL乱码问题解决
      打开 tomcat/conf/server.xml
      查找下面这部分,在最后增加一段代码就可以了。
      <Connector port="80" maxHttpHeaderSize="8192"
      .................
      URIEncoding="UTF-8" useBodyEncodingForURI="true"
      ...............
      />
      其中的UTF-8 请根据你的需要自己修改,比如GBK
      5 虚拟主机配置文件
      tomcat/conf/server.xml
      <!-- 默认的主机 -->
      <Host name="localhost" appBase="webapps"
      unpackWARs="true" autoDeploy="true"
      xmlValidation="false" xmlNamespaceAware="false">
      <Context path="" docBase="ROOT" debug="0" reloadable="true"></Context>
      ...
      </host>
      <!-- 以下是新增的虚拟主机 -->
      <Host name="www.java2000.net" appBase="webapps"
      unpackWARs="true" autoDeploy="true"
      xmlValidation="false" xmlNamespaceAware="false">
      <Context path="" docBase="d:/www.java2000.net" debug="0" reloadable="true"></Context>
      <!-- 虚拟目录 -->
      <Context path="/count" docBase="d:/counter.java2000.net" debug="0" reloadable="true"></Context>
      </Host>
      <Host name="java2000.net" appBase="webapps"
      unpackWARs="true" autoDeploy="true"
      xmlValidation="false" xmlNamespaceAware="false">
      <Context path="" docBase="d:/www.java2000.net" debug="0" reloadable="true"></Context>
      <Context path="/count" docBase="d:/counter.java2000.net" debug="0" reloadable="true"></Context>
      </Host>
      6 数据源配置
      比较复杂,各个版本都有所不同,请直接查看 http://java2000.net/p1906,包括tomcat5.0,tomcat5.5x,tomcat6.0的各个版本的配置方法。
      更多关于Tomcat的使用,请看参考资料

     
    Tomcat配置的10个技巧

      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 。
      必须编辑这个文件,以确定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的绝对路径。
      如果使用的是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或主机数据。为了测试,为本地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”: 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。
      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应用使用它自己的验证方式,而不使用容器管理安全,那你基本上 就没招了。用户每次登录原来所有应用时需要登录一次,并且在请求新的第三方应用时还得再登录一次。
      6> 单点登录需要使用cookies。
      7.配置用户定制目录(Customized User Directores)
      一些站点允许个别用户在服务器上发布网页。例如,一所大学的学院可能想给每一位学生一个公共区域,或者是一个ISP希望给一些web空间给他的客户,但这又不是虚拟主机。在这种情况下,一个典型的方法就是在用户名前面加一个特殊字符(~),作为每位用户的网站,比如:
      http://www.cs.myuniversity.edu/~username提供两种方法在主机上映射这些个人网站,主要使用一对特殊的Listener元素。Listener的className属性应该是 org.apache.catalina.startup.UserConfig,userClass属性应该是几个映射类之一。如果电脑系统是 Unix,它将有一个标准的/etc/passwd文件,该文件中的帐号能够被运行中的Tomcat很容易的读取,该文件指定了用户的主目录,使用 PasswdUserDatabase 映射类。
      http://members.mybigisp.com/~username
      Tomcat
      <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 scripting等,甚至包括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>
      如果没有给出允许主机的指定,那么与拒绝主机匹配的主机就会被拒绝,除此之外的都是允许的。与之类似,如果没有给出拒绝主机的指定,那么与允许主机匹配的主机就会被允许,除此之外的都是拒绝的。
  • Ant需要设置的环境变量

    2009-05-31 15:58:52

    需要设置的环境变量:
    ANT_HOME:ant的安装目录
    JAVA_HOME:jdk的安装目录
    PATH:把%ANT_HOME%\bin目录加到path变量,以便于从命令行下直接运行ant

    假定ant装在c:\ant    jdk装d:\j2sdk1.4.0
    则在命令行下执行以下命令:
    set ANT_HOME=c:\ant
    set JAVA_HOME=D:\j2sdk1.4.0
    set PATH=%PATH%;c:\ant\bin
  • Apache Ant 的build.xml简介

    2009-05-31 15:43:03

    Ant 开发

    Ant的构建文件
    当开始一个新的项目时,首先应该编写Ant构建文件。构建文件定义了构建过程,并被团队开发中每个人使用。Ant构建文件默认命名为build.xml,也可以取其他的名字。只不过在运行的时候把这个命名当作参数传给Ant。构建文件可以放在任何的位置。一般做法是放在项目顶层目录中,这样可以保持项目的简洁和清晰。下面是一个典型的项目层次结构。

    (1) src存放文件。
    (2) class存放编译后的文件。
    (3) lib存放第三方JAR包。
    (4) dist存放打包,发布以后的代码。
    Ant构建文件是XML文件。每个构建文件定义一个唯一的项目(Project元素)。每个项目下可以定义很多目标(target元素),这些目标之间可以有依赖关系。当执行这类目标时,需要执行他们所依赖的目标。每个目标中可以定义多个任务,目标中还定义了所要执行的任务序列。Ant在构建目标时必须调用所定义的任务。任务定义了Ant实际执行的命令。Ant中的任务可以为3类。

    (1) 核心任务。核心任务是Ant自带的任务。
    (2) 可选任务。可选任务实来自第三方的任务,因此需要一个附加的JAR文件。
    (3) 用户自定义的任务。用户自定义的任务实用户自己开发的任务。


    1.<project>标签

    每个构建文件对应一个项目。<project>标签时构建文件的根标签。它可以有多个内在属性,就如代码中所示,其各个属性的含义分别如下。

    (1) default表示默认的运行目标,这个属性是必须的。
    (2) basedir表示项目的基准目录。
    (3) name表示项目名。
    (4) description表示项目的描述。
    每个构建文件都对应于一个项目,但是大型项目经常包含大量的子项目,每一个子项目都可以有自己的构建文件。

    2.<target>标签 
    一个项目标签下可以有一个或多个target标签。一个target标签可以依赖其他的target标签。例如,有一个target用于编译程序,另一个target用于声称可执行文件。在生成可执行文件之前必须先编译该文件,因策可执行文件的target依赖于编译程序的target。Target的所有属性如下。

    (1).name表示标明,这个属性是必须的。
    (2).depends表示依赖的目标。
    (3)if表示仅当属性设置时才执行。
    (4)unless表示当属性没有设置时才执行。
    (5)description表示项目的描述。
    Ant的depends属性指定了target的执行顺序。Ant会依照depends属性中target出现顺序依次执行每个target。在执行之前,首先需要执行它所依赖的target。程序中的名为run的target的depends属性compile,而名为compile的target的depends属性是prepare,所以这几个target执行的顺序是prepare->compile->run。

    一个target只能被执行一次,即使有多个target依赖于它。如果没有if或unless属性,target总会被执行。

    3.<mkdir>标签
    该标签用于创建一个目录,它有一个属性dir用来指定所创建的目录名,其代码如下:
    <mkdir dir=”${class.root}”/>
    通过以上代码就创建了一个目录,这个目录已经被前面的property标签所指定。

    4<jar>标签
    该标签用来生成一个JAR文件,其属性如下。
    (1) destfile表示JAR文件名。
    (2) basedir表示被归档的文件名。
    (3) includes表示别归档的文件模式。
    (4) exchudes表示被排除的文件模式。

    5.<javac标签>
    该标签用于编译一个或一组java文件,其属性如下。
    (1).srcdir表示源程序的目录。
    (2).destdir表示class文件的输出目录。
    (3).include表示被编译的文件的模式。
    (4).excludes表示被排除的文件的模式。
    (5).classpath表示所使用的类路径。
    (6).debug表示包含的调试信息。
    (7).optimize表示是否使用优化。
    (8).verbose 表示提供详细的输出信息。
    (9).fileonerror表示当碰到错误就自动停止。

    6.<java>标签
    该标签用来执行编译生成的.class文件,其属性如下。
    (1).classname 表示将执行的类名。
    (2).jar表示包含该类的JAR文件名。
    (3).classpath所表示用到的类路径。
    (4).fork表示在一个新的虚拟机中运行该类。
    (5).failonerror表示当出现错误时自动停止。
    (6).output 表示输出文件。
    (7).append表示追加或者覆盖默认文件。

    7.<delete>标签
    该标签用于删除一个文件或一组文件,去属性如下。
    (1)/file表示要删除的文件。
    (2).dir表示要删除的目录。
    (3).includeEmptyDirs 表示指定是否要删除空目录,默认值是删除。
    (4).failonerror 表示指定当碰到错误是否停止,默认值是自动停止。
    (5).verbose表示指定是否列出所删除的文件,默认值为不列出。

    8.<copy>标签
    该标签用于文件或文件集的拷贝,其属性如下。
    (1).file 表示源文件。
    (2).tofile 表示目标文件。
    (3).todir 表示目标目录。
    (4).overwrite 表示指定是否覆盖目标文件,默认值是不覆盖。
    (5).includeEmptyDirs 表示制定是否拷贝空目录,默认值为拷贝。
    (6).failonerror 表示指定如目标没有发现是否自动停止,默认值是停止。
    (7).verbose 表示制定是否显示详细信息,默认值不显示。

    Ant的数据类型
    在构建文件中为了标识文件或文件组,经常需要使用数据类型。数据类型包含在org.apache.tool.ant.types包中。下面镜简单介绍构建文件中一些常用的数据类型。

    1. argument 类型
    由Ant构建文件调用的程序,可以通过<arg>元素向其传递命令行参数,如apply,exec和java任

    务均可接受嵌套<arg>元素,可以为各自的过程调用指定参数。以下是<arg>的所有属性。
    (1).values 是一个命令参数。如果参数种有空格,但又想将它作为单独一个值,则使用此属性。

    (2).file表示一个参数的文件名。在构建文件中,此文件名相对于当前的工作目录。
    (3).line表示用空格分隔的多个参数列表。
    (4).path表示路径。

    2.ervironment 类型
    由Ant构建文件调用的外部命令或程序,<env>元素制定了哪些环境变量要传递给正在执行的系统命令,<env>元素可以接受以下属性。

    (1).file表示环境变量值得文件名。此文件名要被转换位一个绝对路径。
    (2).path表示环境变量的路径。Ant会将它转换为一个本地约定。
    (3).value 表示环境变量的一个直接变量。
    (4).key 表示环境变量名。
    注意 file path 或 value只能取一个。

    3.filelist类型
    Filelist 是一个支持命名的文件列表的数据类型,包含在一个filelist类型中的文件不一定是存在的文件。以下是其所有的属性。

    (1).dir是用于计算绝对文件名的目录。
    (2).files 是用逗号分隔的文件名列表。
    (3).refid 是对某处定义的一个<filelist>的引用。
    注意 dir 和 files 都是必要的,除非指定了refid(这种情况下,dir和files都不允许使用)。

    4.fileset类型
    Fileset 数据类型定义了一组文件,并通常表示为<fileset>元素。不过,许多ant任务构建成了隐式的fileset,这说明他们支持所有的fileset属性和嵌套元素。以下为fileset 的属性列表。

    (1).dir表示fileset 的基目录。
    (2).casesensitive的值如果为false,那么匹配文件名时,fileset不是区分大小写的,其默认值为true.

    (3).defaultexcludes 用来确定是否使用默认的排除模式,默认为true。
    (4).excludes 是用逗号分隔的需要派出的文件模式列表。
    (5).excludesfile 表示每行包含一个排除模式的文件的文件名。
    (6).includes 是用逗号分隔的,需要包含的文件模式列表。
    (7).includesfile 表示每行包括一个包含模式的文件名。

    5.patternset 类型 
    Fileset 是对文件的分组,而patternset是对模式的分组,他们是紧密相关的概念。

    <patternset>支持4个属性:includes excludex includexfile 和 excludesfile,与fileset相同。Patternset 还允许以下嵌套元素:include,exclude,includefile 和 excludesfile.

    6.filterset 类型
    Filterset定义了一组过滤器,这些过滤器将在文件移动或复制时完成文件的文本替换。
    主要属性如下:
    (1).begintoken 表示嵌套过滤器所搜索的记号,这是标识其开始的字符串。
    (2).endtoken表示嵌套过滤器所搜索的记号这是标识其结束的字符串。
    (3).id是过滤器的唯一标志符。
    (4).refid是对构建文件中某处定义一个过滤器的引用。

    7.Path类型 
    Path元素用来表示一个类路径,不过它还可以用于表示其他的路径。在用作揖个属性时,路经中的各项用分号或冒号隔开。在构建的时候,此分隔符将代替当前平台中所有的路径分隔符,其拥有的属性如下。

    (1).location 表示一个文件或目录。Ant在内部将此扩展为一个绝对路径。
    (2).refid 是对当前构建文件中某处定义的一个path的引用。
    (3).path表示一个文件或路径名列表。

    8.mapper类型
    Mapper类型定义了一组输入文件和一组输出文件间的关系,其属性如下。
    (1).classname 表示实现mapper类的类名。当内置mapper不满足要求时,用于创建定制mapper.
    (2).classpath表示查找一个定制mapper时所用的类型路径。
    (3).classpathref是对某处定义的一个类路径的引用。
    (4).from属性的含义取决于所用的mapper.
    (5).to属性的含义取决于所用的mapper.
    (6).type属性的取值为identity,flatten glob merge regexp 其中之一,它定义了要是用的内置mapper的类型。


    Ant 的运行
    安装好Ant并且配置好路径之后,在命令行中切换到构建文件的目录,输入Ant命令就可以运行Ant.若没有指定任何参数,Ant会在当前目录下查询build.xml文件。如果找到了就用该文件作为构建文件。如果使用了 –find 选项,Ant 就会在上级目录中找构建文件,直至到达文件系统得跟目录。如果构建文件的名字不是build.xml ,则Ant运行的时候就可以使用 –buildfile file,这里file 指定了要使用的构建文件的名称,示例如下:

    Ant
    如下说明了表示当前目录的构建文件为build.xml 运行 ant 执行默认的目标。

    Ant –buildfile test.xml
    使用当前目录下的test.xml 文件运行Ant ,执行默认的目标。

  • Apache Ant 简介

    2009-05-31 14:33:04

    (官方网站:http://ant.apache.org/)

    Apache Ant is a Java-based build tool. In theory, it is kind of like Make, but without Make's wrinkles.

    Why another build tool when there is already makegnumakenmakejam, and others? Because all those tools have limitations that Ant's original author couldn't live with when developing software across multiple platforms. Make-like tools are inherently shell-based -- they evaluate a set of dependencies, then execute commands not unlike what you would issue in a shell. This means that you can easily extend these tools by using or writing any program for the OS that you are working on. However, this also means that you limit yourself to the OS, or at least the OS type such as Unix, that you are working on.

    Makefiles are inherently evil as well. Anybody who has worked on them for any time has run into the dreaded tab problem. "Is my command not executing because I have a space in front of my tab!!!" said the original author of Ant way too many times. Tools like Jam took care of this to a great degree, but still have yet another format to use and remember.

    Ant is different. Instead of a model where it is extended with shell-based commands, Ant is extended using Java classes. Instead of writing shell commands, the configuration files are XML-based, calling out a target tree where various tasks get executed. Each task is run by an object that implements a particular Task interface.

    Granted, this removes some of the expressive power that is inherent by being able to construct a shell command such as `find . -name foo -exec rm {}`, but it gives you the ability to be cross platform. -- to work anywhere and everywhere. And hey, if you really need to execute a shell command, Ant has an <exec> task that allows different commands to be executed based on the OS that it is executing on.

    Ant是一种基于Java的build工具。理论上来说,它有些类似于(Unix)C中的make ,但没有make的缺陷。 既然我们已经有了make, gnumake, nmake, jam以及其他的build工具为什么还要要一种新的build工具呢?因为Ant的原作者在多种(硬件)平台上开发软件时,无法忍受这些工具的限制和不 便。类似于make的工具本质上是基于shell(语言)的:他们计算依赖关系,然后执行命令(这些命令与你在命令行敲的命令没太大区别)。这就意味着你 可以很容易地通过使用OS特有的或编写新的(命令)程序扩展该工具;然而,这也意味着你将自己限制在了特定的OS,或特定的OS类型上,如 Unix。

    Makefile有一些不足之处,比如很多人都会碰到的烦人的Tab问题。最初的Ant开发者多次强调”只是我在Tab前面加了一个空格,所以我的命令就不能执行”。有一些工具在一定程度上解决了这个问题,但还是有很多其他的问题。

    Ant则与一般基于命令的工具有所不同,它是Java类的扩展。Ant运行需要的XML格式的文件不是Shell命令文件。它是由一个Project组成的,而一个Project又可分成可多target,target再细分又分成很多task,每一个task都是通过一个实现特定接口的java类来完成的。

    Ant的优点: Ant是Apache软件基金会JAKARTA目录中的一个子项目,它有以下的优点。 跨平台性。Ant是纯Java语言编写的,所以具有很好的跨平台性。 操作简单。Ant是由一个内置任务和可选任务组成的。Ant运行时需要一个XML文件(构建文件)。 Ant通过调用target树,就可以执行各种task。每个task实现了特定接口对象。由于Ant构建文件是XML格式的文件,所以很容易维护和书写,而且结构很清晰。Ant可以集成到开发环境中。由于Ant的跨平台性和操作简单的特点,它很容易集成到一些开发环境中去。




Open Toolbar