Maven+Spring+MVC结构中,jetty/tomcat是如何启动项目的

针对maven配置的Spring+MVC项目,我们用Maven自带的jetty和tomcat插件进行调试,这很方便。但是调试时,这些插件所启动的web服务器,是如何来将我们的工程作为一个web项目启动并运行,可能并没有看上去那么简单。搞清楚它们启动时,是如何引用我们的项目,就是这的目的。

Maven+Spring+MVC结构中,jetty/tomcat是如何启动项目的_第1张图片

如果项目的名称是mvn_mvc,那么整个目录结构就如上图。

通常我们首先用mvn package生成上述的target目录中带红色部分。其等效执行 mvn compile test-compile test war:exploded war:war。也就是包含编译、测试和打包三步骤。接下来我们就可以使用mvn jetty:run或者mvn tomcat:run进行网站启动,测试运行了。此时会对应生成临时的jsp目录,jetty对应的目录名是work,tomcat对应的目录名是tomcat。

那么,项目对应的目录就是target/mvn_mvc目录吗?

非也非也!!!

真正的项目目录应该是:

  1. 本项目的java类来自于target/classes
  2. 本项目依赖的jar包来自于maven的pom配置(并没有实际的物理目录,为maven插件动态组织管理)
  3. 本项目依赖的配置文件和静态资源来自于src/main/webapp

综上所述,可以得到两个结论就是:

  • 运行时,其实和target/mvn_mvc这个目录(打包项目目录)没有任何关系。所以如果运行过程中如果修改了这个目录的动态class和静态文件,就看不到效果。必须改src/main/java和src/main/webapp的才行。
  • 另外,maven设计的项目思想是:src目录下是纯本项目的代码,没有任何临时文件和依赖jar包。这样也便于代码的管理:自己写的是自己的,别人的机器的都放到别处

如果程序调试出现异常,就按照此方法检查。

譬如,再经过再一次的去maven大爷的痛苦经历后,终于明白了以前碰到的一个问题:

在调试过程中,发现弹出这么一个框,标题是obsolete methods on the stack。现象就是:更新的代码在调试中不起作用。

最后找到原因:不知道什么时候,在src/main/webapp/WEB_INF中出现了classes和lib目录。这会导致始终以这个目录的classes为源代码;和调试的我们的真正源代码java不一致。删掉它们才解决。

你可能感兴趣的:(Maven+Spring+MVC结构中,jetty/tomcat是如何启动项目的)