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，