调试笔记
在使用Tomcat过程中经常碰到问题，导致tomcat启动失败。如下↓
由于报错太过笼统，我根本无法找出错误。后来我切换到Console视图下，看到了如下错误信息。
根据报错信息，错误原因是32bit 的Tomcat不能在AMD 64-bit的platform 上面运行，但是经过查看我发现自己的tomcat和java都是64bit的。
查看tomcat的版本号的链接：→
http://jingyan.baidu.com/article/e73e26c0c4b40024adb6a789.html
或者在如下图的路径下，打开 DOS命令行，将bin目录下的 version.bat 拖入DOS窗口，即可看到 Tomacat的版本号及其平台的bit。
查看java（VM）的版本信息如下：
在设置环境变量之后，可以通过cmd→java -version查看版本号，设置环境变量方法如下：
http://jingyan.baidu.com/article/c85b7a6414f2ee003bac95d5.html
通过以上两图，我们可以看到，tomcat和java vm都是64位，那么为什么会报错呢。我去网上查看了一些方法，但都没有解决我的问题。于是我重新去网上下载了报错文件“tcnative-1.dll”发现“native method Initial”证明native method结束，但是由于重新下载的“tcnative-1”的版本不对，所以报出另一个错误。所以我们可以判断，报错的原因在于“tcnative-1.dll”文件中描述的是32位系统的（至于为什么我也不知道）。所以我去网上重新下载新的Tomcat为了防止报错，我下载了64位/32位集合版。
安装并配置完成后（安装方法和配置流程在上述链接中均有涉及），重新运行。为了验证服务器是否正常，首先运行了“buy”（已无错误）工程，发现能正常运行。然后再运行“medical”发现，服务器再一次报错。
还是一样，这个图并不能说明什么，再次来到console视图，看到错误代码如下：
java.util.concurrent.ExecutionException: org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/medical]]
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:192)
at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:1123)
at org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:799)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1559)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1549)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/medical]]
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154)
... 6 more
Caused by: java.lang.IllegalArgumentException: The servlets named [RecInfoServlet] and [com.xiazi.servlet.RecInfoServlet] are both mapped to the url-pattern [/RecInfoServlet] which is not permitted
at org.apache.catalina.deploy.WebXml.addServletMapping(WebXml.java:293)
at org.apache.catalina.startup.ContextConfig.processAnnotationWebServlet(ContextConfig.java:2393)
at org.apache.catalina.startup.ContextConfig.processAnnotationsStream(ContextConfig.java:2069)
at org.apache.catalina.startup.ContextConfig.processAnnotationsFile(ContextConfig.java:2030)
at org.apache.catalina.startup.ContextConfig.processAnnotationsFile(ContextConfig.java:2023)
at org.apache.catalina.startup.ContextConfig.processAnnotationsFile(ContextConfig.java:2023)
at org.apache.catalina.startup.ContextConfig.processAnnotationsFile(ContextConfig.java:2023)
at org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1288)
at org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:873)
at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:371)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5355)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
... 6 more
从上述中我们可以得到报错信息如下：
java.util.concurrent.ExecutionException: org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/medical]]
Caused by: java.lang.IllegalArgumentException: The servlets named [RecInfoServlet] and
[com.xiazi.servlet.RecInfoServlet] are both mapped to the url-pattern [/RecInfoServlet] which is not permitted
也就是因为两个同名文件共同映射至<url-pattern>而报错，然后通过查询相关解决方法，发现一般人都是因为<url -pattern>内的路径少了”/”(当前路径)的问题，而我并不是因为这个问题。
于是我开始思考，为什么会报错。反而言之，为什么只有一个“RecInfoServlet”会报错。我开始思考：
1.我们对不同的文件进行了重名注册，这明显是最可能出现的情况。但经过改名，排查了该错误。
2.可能是：当我们对同一个servlet进行两次注册时，会不会被编译器判定为两个servlet的同一次注册呢？我开始review我的“RecInfoServlet”，果然我发现了问题。
对比发现，在出错的代码中有servlet向导默认生成的注解，@WebServlet(“.......”)，而未报错的servlet中的注解在写代码时，被我删掉。突然意识到，在编写servlet初期，老师强调过要将默认生成的@WebSevlet删掉。因此我删掉了，这行代码。
那么为什么会报错呢，我通过在StackExchange中查找相似的案例，找到了一例。链接如下：
这位跟我发生了相同的错误，下面有解答如下：
也就是说，默认生成的注解“@WebServlet”和我们的部署文件“web.xml”发生了冲突，同一个servlet被注册了两遍，而编译器认为是不同servlet发生了重名。证实了猜想二。
通过这次解决问题，我对tomcat有了一个新的认识。在阅读web.xml和server.xml时，我学到了很多东西。
1.当我运行了一次错误的“medical”之后再去运行正确的“buy”项目，发现服务器会报错，无法开启。通过server.xml代码我发现，每次给服务器加载新的项目时，服务器会有如下声明：
<Context docBase="Buy" path="/Buy" reloadable="true" source="org.eclipse.jst.jee.server:Buy"/><Context docBase="medical" path="/medical" reloadable="true" source="org.eclipse.jst.jee.server:medical"/></Host>
也就是在<host>中会声明加入的工程。而代码自上往下，自左往右的编译过程，导致服务器首先阅读的是错误的“medical”项目配置，而阅读到“Buy”项目时，就发生端口【8005】已被占用的情况。所以当我们需要对服务器进行查错时，首先应该删除server.xml中多余的工程。也可以通过图形化界面将工程移出服务器。
2.当我对web.xml进行阅读的时候，发现了两个web.xml，分别在webcontent下和servers。
我猜想，这大概就是在servlet中加入@WebServlet注解会报错，而平时需要删除注解的原因了。
在阅读WebContent/web.xml时我发现了有趣的部分：
在此处，我们可以看到对6种页面的声明为<welcome-file>也就是我们运行工程时默认首先开启的主页，优先级从上到下。那么在我们有的时候给主页换名时(或者是重新指定主页)，我们需要在换名后，来到web.xml对以上代码进行，相应的修改。
而在Server/web.xml中，我们居然发现了更有趣的部分：
也就是说，我们可以指定所有在服务器上运行项目的默认主页。It’s so cool.
总结
本次排错，历时8小时有余，收获颇丰。对于服务器和编译器的认识，也发生了巨大的改变，以前认为编译器不会错，现在发现，编译器有的地方也是不合理的。服务器就更奇怪了，各种奇葩的错误也是层出不穷。
在对第二个问题排错时，最有可能的错误没有发生，而相对不可能的错误却发生了。证明在程序界和侦探界有句话是统一的：排除了所有可能，剩下的任何不可能都有可能是真相。
我也学会怎么通过Console来检查和排除错误，这一点在编程生涯中，会让我受益无穷。作为一个web开发者，接下来我应该学会怎么利用浏览器查错排错。