Tomcat源码组织结构

Tomcat 源码组织结构

目录结构

这里所介绍的目录结构，是使用CATALINA-BASE变量定义的路径，如果没有通过配置多个CATALINA-BASE目录来使用多实例，则CATALINA-BASE和CATALINA-HOME值相同，也就是tomcat安装的目录。

推荐使用的关键点，就是将源码层次结构和生产部署的应用程序层次结构分开，这种分开有以下几个好处：

1. 在源码目录里面的内容，可以简单的修改、移动、打包，因为可执行的应用程序版本并不在该目录中；
2. 源码目录更好被控制，因为里面只有源码
3. 当需要将应用程序发布出去再建立一个实例，分开布放会更简单

Ant开发工具，就是用来创建和处理这些层次结构的。

对于管理员来说，用来控制应用程序源码的目录和文件层次可能更有吸引力，所以，下面要讲介绍的组织会更适用。使用的配置文件也就是build.xml文件，在源码目录下的根节点，以下的这些目录都是存在的：

1. docs目录，用来存放应用程序的文件，
2. src目录，用来创建程序的java源码、封装bean或者是只有该实例应用程序才会使用的单独的Java类，如果源码被封装在一个压缩包里面，则压缩包里面的层次结构，必须和该目录下的目录结构对应
3. web目录，web站点的静态资源内容，JSP和JS、CSS样式文件和图像，这些资源都会被client直接访问到，这个站点，是web应用程序的根目录站点，然后这个目录下的所有子目录结构，都会对应到访问这些文件的URL上面
4. web/web-inf目录，应用程序所需的特殊的配置文件，包含站点部署的xml文件，自己创建的用户标记库的标记描述文件，和其他希望在站点中被访问的资源，这个站点相当于web应用程序根目录的子目录，但是程序配置文件不允许client直接访问该目录下的内容。也就是说，这个目录下可以用来存放一些敏感信息，只用于应用程序，比如数据库连接器的参数

在开发环境中，会有两个单独的目录

1. build目录，当执行默认的build程序时，也就是执行ant，目录中就会包含应用程序压缩包中的完整的文件镜像，tomcat允许直接使用未解压的目录来部署应用程序，不需要将这些内容，拷贝到 $CATALINA_BASE/webapps目录下，或者是通过manager来安装程序。这种方式，在开发环境中特别适用。
2. dist目录，当在执行ant dist时，会创建该目录，会创建一个应用程序的实时二进制文件镜像，包含授权信息、文档等其他文件。

这俩目录不能是压缩包的形式，因为在开发部署的过程中，这俩目录是会被删除和被创建的，正因为这个原因，如果是为了维护性能来记录变化，不允许编辑这俩目录下的 任何源文件，因为这些优化会在下一次编译的时候丢失。

外部依赖

当应用程序需要一个其他的jar文件或者其他资源时，而这些资源来源于其他外部的工程或者是包，最简单的例子，当应用程序需要使用一个数据源，也就是需要一个JDBC驱动器。

不同的开发人员，会选择使用不同的合适的方法来解决这个问题，有一些人会推荐将所依赖的jar文件进行一次拷贝，然后复制到所有需要改jar文件的应用程序的源码控制压缩包中，然而当在多个应用程序中使用同一个jar文件时，当需要对这个jar文件进行更新时，这就需要对多个位置的文件进行更新。

因此，就会推荐不将该文件拷贝到应用程序的源码压缩包里面，替换的方法是将该外部依赖包集成到应用程序的编译过程中。通过这种方法，只需要选择合适版本的jar文件，而不需要在当jar文件发生更新时，去担心应用程序。

比如ant build.xml文件时，需要指定需要拷贝文件的位置，当这些文件发生改变时，不需要修改build.xml，这些编译参数可以基于每一个应用程序集进行自定义，或者是使用家目录下的默认标准编译参数。

在很多情况下，系统开发人员已经在tomcat的lib目录下安装了所需的jar文件，根本不需要做其他的操作，build.xml中自动就包含了这些文件的完整路径。

 

源码控制

正如之前提到的，强烈推荐将组成应用系统的源码，存放在一个类似于CVS的源码控制系统中，如果选择这么做，在源码层次中的每一个目录和文件都应该被登记和保存，但是不会产生新的文件，如果注册了二进制文件，同时需要向源码控制系统说明。

建议不要将build和dist目录下的文件保存在源码控制系统中，一个简单的方法来告诉CVS系统去忽略这些目录，是在源码根目录中指定一个.cvxignore文件，内容包含build和dist即可。

 

编译XML配置文件

在tomcat中，会使用ant来管理java源码文件的兼容性，同时创建实施的层次结构，ant的操作是在一个名为build.xml的配置文件的控制下进行的，该文件中定义了需要操作的步骤，该文件存放在源码层次结构的根部木了下，在源码控制系统中会被检查。

和其他编译文件类似，build.xml提供了许多参数，来支持其他的开发活动，比如创建相关联的java文档，清空开发环境家目录，为应用程序打包分发到其他地方，一个好的build.xml中应该包含内部注释，描述这些参数的功能，通过ant -projecthelp来显示工程文档，改变目录中包含的内容和格式。

从头开始，基础的build.xml文件，让应用程序可以被自定义和安装源码目录，在该文件中描述了可以执行的多种参数，通常包含以下几个：

1. clean，会删除已经存在的build和dist目录，可以通过擦除来重新建立，这可以保证不会对源码做改变，防止出现兼容性问题；
2. compile，该参数用来编译所有变更的源码，会在build目录下的子目录web-inf/classes中创建结果类文件，而且应用程序的结构文件也是精确的，在开发过程中，这条命令是最频繁被使用的，所以通常是默认的参数；
3. all，这个参数是先执行clean，后执行compile，这可以保证对整个应用程序进行了编译，保证不会有未知的兼容性问题。
4. dist，该参数会为当前的应用程序产生一个副本，包含所有相关的文档、javadoc，然后将应用程序压缩包传递给相关系统进行部署，这个参数以来与deploy参数，应用程序的压缩包同样会将部署时间的所有外部依赖进行打包；
5. Javadoc，该参数会将整个web应用程序中的java类创建javadoc API文档，假设在build.xml需要在应用发布的时候包含所有的API文档，使用这个参数，就会在dist目录下创建一个子目录，将这些文档全部生成。正常在每次编译过程中是不需要产生这些文档的，这个参数是一个独立的参数，并不是贬义的参数；
6. Install，该参数是告诉tomcat，现在操作的应用程序在部署完成后就可以立即被使用，在这个过程中，是不需要tomcat重启的，但是这个参数也是一次性的，下一次tomcat重启的时候不会再使用
7. Reload，一旦应用程序已经被安装上之后，可以通过compile参数继续更新和变更，tomcat会自动的识别jsp页面的变更，但是不能识别其他内容，这个参数是用来告诉tomcat来重启当前已经被安装的应用程序，以便识别这些更新
8. Remove，