关于web项目部署以及迁移再‘追记’一下

    之前一直在用idea社区版，竟然不能集成tomcat运行，最后没有办法只能用maven-tomcat-plugin来跑， 前面用着还挺顺手的，但是后面由于练习需要，得配置多个context，即多个web项目用于读取图片。  这下难题来了，网上各种找资料，都没有找到合适的。自己也打算去配置，或者去看官方说明文档，但是考虑到可能要花费很多时间，只能作罢。

    然后将项目整体从社区版搬到专业版上面来，之前一直以为这个迁移很麻烦，其实也没有。  就是注意在复制粘贴的时候，要考虑到类的包结构，复制粘贴相应的源代码包带对应的源代码路径下，不然的话包结构会打乱，会涉及到很多的修改，变得很麻烦。   应为之前是一个maven工程，而搬迁过来的是 web工程，因此，结构上面有一些区别。 其实这些只是按照ide的法则构建的包，实际编译构建后的包跟原来的包路径是没有多大联系的，所以从这一意义上来说，各种五花八门的ide反而增加我们对原本程序的理解难度。 

    需要注意的是，我们除了要复制元源代码路径，还要把我们的一些配置文件给复制过去，并且我们复制过去了之后，要将其设置为配置目录的根路径，方法为：

         

    我们可以分别将自己的测试路径，源代码路径考进来。  并且配置让ide识别出来。  

    另外一个比较奇怪的就是，这些我们能配置，那么如何让ide识别我们的目录结构为web项目呢？、

            一种方法就是完全新建一个webApplicaton项目，然后复制粘贴进来，当然，这种方法显得不怎么高档了，作为一个程序员逼格不够。

             另一种方法就是： 我们手动让ide识别我们这个是一个web项目，就idea而言，识别的标志是这样的： 。  怎么做呢？  上图把：

                    

 

    配置完后，点击apply。   

    然后 ，点击ok。   回去看，达到我们的效果了。  欧了。 

    接下来记录下我们部署的时候选项的区别吧：  上图:

                

    可以看到他给我们提供了两个选项： artifact (成品，制品)，以及external Source。   artifact是idea作为一个导出的配置而设置的，因为之前导出java Application也设置过这个。 配置方式如下： 

                

 

    那么它们有什么区别呢？  external Source其实就是选择已经build成功的war包，然后作为一个web项目给配置到tomcat里面。  而artifact是我们已经配置过，但是没有build的项目，我们再选择的时候它会自动给我们识别出来。 这里关于build有多种途径，常见的如点击右键，选择build... 的。   另外还有一种就是：点击然后就可以了。   有时候我们点击配置的时候可能没有artifact的选项，这时候可以现在上面第二张图的底部加上一个  build artifact选项就可以了。   

     关于配置都弄好了，接下来就是运行了。  

      之前再用eclipse好像没有怎么注意，就是在ide集成的时候，可以配置访问路径，也就是说不按照我们的项目名称去访问，而是按照我们设定的去访问，像这样： 。

       唐僧西天取经，历经九九八十难，还差一难。    

        因此我们肯定还必须得克服一个困难才能取到真经。  嘿嘿。

        让项目跑起来吧，走你！    一切看似都如此正常。 

        进入浏览器，发现出现404，而且后台这边控制台除了第一次能够接收到打印的消息，显示了一个 spring-dispatcher 初始化完成后就没有下文了。 

        现在判断有两个可能原因，并且其中一个已经被证实：

                一，tomcat7.0以及一下的版本不支持  web3.0应用，或者不支持spring 4还是什么的，具体记不太清了，但是这里有一个坑，记录一下以后才能绕开。

                二，spirng-mvc配置没有生效，可能是由于没有正确配置读取  resources ，即配置文件的根路径。 

        关于版本的问题现在能记住的应该有三次遇到过：  第一个就是今天这个问题；  第二个是 用jdk9跟较低版本eclipse集成的时候会报错。  第三个是：spring与 fast-json配置集成的时候由于版本问题抛错。   之前一直的理念就是 版本都是向下兼容的，看来不尽然。   除了这几个例子，还有一个鲜明的例子就是python2,与python3，它们甚至不兼容。  所以，这些坑能绕就绕。  你说一个小小的程序员碰到业务bug或者配置问题倒还能勉强应付一下，碰到这种版本不兼容，非功能性问题的时候只能干瞪眼哈哈哈哈，而且还会花费大量的时间去处理，最后才发现是这么个问题，后面简直要吐血而亡。    

        最后一点记录一下，就是我们配置了那些  marked directory as .. 有什么用呢？  举个简单的例子：   

            

    编译器帮我们做的事情如下： 

                

        可以非常惊奇的看到：  它把这些东西放到了它们应该在的地方，嘻嘻。   比如resources,比如配置文件。 

        快上课了，在记录一下另外几个文件夹的理解吧。 不一定准确：  .ideal记录了这个项目的相关信息，比如改动记录，比如项目的依赖等等，目录结构。   相对的，campusStore.iml记录的则是这个模块的相关信息。 

       嗯就这样，加油！