【操作步骤】
1.在云服务器上安装Memcache

2.在本地和云服务器上都部署上ITtask_4,把Memcache服务开在云服务器上。

3.在云服务器上部署项目失败，原因：抛异常。异常提示：java.lang.NoSuchMethodError:....。可以确定是jar包版本冲突导致，接下来的任务就是解决jar包冲突问题。

4.解决了jar包冲突的问题，接下来把ITtask_4项目部署在本地的tomcat和jetty上。


【知识总结】
1.Java Servlet Server的URL通常的格式为：http://hostname.com/contextPath/servletPath/pathInfo。

2.在我建立的Maven webapp项目的目录结构下，有一个Libraries文件夹，这个文件夹下有四个文件夹：EAR Libraries（该文件夹为空）、JRE System Library、Maven Dependencies、Web App Libraries。
  我查了一些资料，感觉这四个文件夹的作用大概是这样的：
    2.1 EAR Libraries：开发EJB工程所需的库包，现在不需要，为空。
    2.2 JRE System Library：主要存放J2SE的标准jar，一般不需要调整。
    2.3 Maven Dependencies：当我在pom.xml中导入jar包时，都会在这个文件夹中出现，其目的是让web工程能够在eclipse开发环境可以正常编译，不报错。
    2.4 Web App Libraries：主要作用是让eclipse导出war包的时候，会把其目录下的所有jar或者项目中的工程引用都导出到WEB-INF/lib文件夹下。

注意：编译期冲突是由Maven Dependencies中jar包冲突引起；运行期冲突是由 Web App Libraries下jar文件冲突引起的。

再注意：通常情况下，如果项目编译正常，但部署后抛异常，且这个异常是：java.lang.NoSuchMethodError:....那么基本可以断定，是由于WEB-INF/lib文件夹下的jar包版本冲突导致。

3.在jetty上动态部署项目的方法，以前我都是直接把打好的war包放到webapps目录下的，这种方法叫做静态部署，不提倡，提倡的是动态部署，灵活性很高。方法：(1)把生成的war包放到/home目录下（这个随便啦），在jetty/webapps目录下新建一个xml文件（例如ITtask_4.xml），在这个xml文件上进行配置，主要配置两个内容，一个是上下文路径，一个是war包路径，示例：
    <Configure class="org.eclipse.jetty.webapp.WebAppContext">
      <Set name="contextPath">/ITtask_4</Set>
      <Set name="war">/home/ITtask_4.war</Set>
    </Configure>
  关于上下文路径这个参数，其实很简单，就是跟在域名后面的那个东西。

【出现的问题（已解决）】
1.解决了一个大问题，爽到爆炸！
    1.1 问题描述：前两天，任务需要部署两台web来进行负载均衡测试，一开始我想把项目部署在本地的jetty和tomcat上，结果失败，原因是当我把打包好的war文件放到tomcat/webapps目录下并启动tomcat后，会抛异常：java.lang.NoSuchMethodError。我也试过更换tomcat版本，但是情况并没有好转，我断定是spring框架版本的问题。于是放弃了把项目部署到tomcat上这个想法，转而想把项目部署到云服务器的jetty上，当我把war包上传到云服务器上并启动jetty时，出现了同样的状况，也是抛java.lang.NoSuchMethodError这个异常。这可就诡异了，我在本地明明可以用jetty正常启动，为什么部署到云服务器的jetty上就启动不了了呢？
    1.2 原因：其实出现这个现象的根本原因是jar包版本冲突，我后来看了一下WEB-INF/lib目录下的jar包，有好多重复的，像spring-webmvc这个jar包，就有3.1.3、3.2.8和4.2.4三个版本，这三个放一块儿，你说让人家调用哪个包，所以就冲突了。而之所以我为什么在本地jetty能够启动项目，在服务器jetty上却启动不了，原因是因为我在本地启动项目时，并不是把war包部署到本地jetty/webapps目录下，然后启动jetty的，而是在项目的pom.xml同级文件夹下，利用mvn jetty:run的命令启动的，这两种启动方式还是很有区别的。
    1.3 解决的办法：首先，通过pom.xml文件的Dependency Hierarchy视图就可以看到jar包之间的依赖关系，把有冲突的jar包依赖排除掉就可以，排除的方法有两种：(1)例如，我的项目主要是使用spring 3.2.8版本的，那么就要剔除掉3.1.1和4.2.4这两个版本重复的jar包。在Dependency Hierarchy视图下，我发现我项目中引入的mybatis-spring.1.1.1.jar依赖于spring-webmvc.3.1.1.jar，于是，我就在spring-webmvc.3.1.1.jar上右键->Exclude Maven Artifact就可以了。(2)第二种方法就是直接在pom.xml文件中进行修改，在引用mybatis-spring.1.1.1.jar的地方加上<exclusion></exclusion>标签，把spring-webmvc剔除掉就好。其实这两个方法算是一种方法，因为最后的效果都是在pom.xml文件中添加上了<exclusion>标签。
    1.4 其他注意事项：
        (1)查看jar包依赖还有一种方法，就是通过命令mvc dependency:tree来查看，而且命令mvc dependency --> tree.txt还可以把依赖树输出到一个tree.txt文件中方便查看。但是我感觉这种方法得到的依赖树不全，明明我3.1.1版本的spring-webmvc包冲突了，但是在命令生成的依赖树中并没有看到spring-webmvc.3.1.1.jar的身影，奇了个怪。
        (2)当使用mvn install命令生成war文件时，会在WEB-INF/lib目录下加上项目所需要的jar包。如果在项目编写过程中更换了很多次jar包版本，并且多次使用install命令时，会在WEB-INF/lib目录下添加上很多重复的jar包，此时可以把WEB-ING/lib目录下的所有jar包都删除掉，重新install就好了。
        (3)当使用mvn conpile命令编译项目时，会在/home/.m2目录下添加上pom.xml中引入的jar包。所以当感觉jar包引用过于冗余时，不妨把整个.m2文件夹都删除掉，重新编译。（我用的是ubuntu系统，不知道在windows下是哪个文件夹）
        (4)jetty即是个软件，也是个插件。说它能当作软件用，是指可以把项目war包放在jetty/webapps目录下，使用java -jar start.jar的方法启动jetty；说它能当作插件用，是指可以直接在pom.xml中配置maven-jetty-plugin，然后通过mvn jetty:run的方式启动项目。这也是为什么我能够通过mvn jetty:run的方式启动项目，但是却不能通过war包的方式部署项目，因为这两种方法根本就采用的是两个jetty。（当然，这一点是我自己想的，对不对就不知道了，我感觉肯定是这样的）
        (5)还有一个奇怪的地方。一开始我在pom.xml文件中只引用了spring-webmvc这个jar包，然后它自动就会把core、beans、orm、context这些jar包都引进来，但是结果是在部署项目的时候起了冲突，后来我在pom.xml中把这些jar包都明明白白地引入了进来，问题就解决了，很奇怪，所以以后还是用到哪个包就把哪个包引进来比较妥当。


【出现的问题（未解决）】
1.明天开始进行负载均衡测试。




【疑问】