springboot实操笔记

    今天就动手做了。  记录下过程,以期能够多理解一些。

    首先加入<parent>spring-boot-starter-parent</parent>

    

    更新后,查看项目的依赖,没有任何变化。

    查看本地的.m2,文件,将文件按照时间排序,没有在当前时间节点添加了本地文件或者修改文件夹信息等等。

    之后有意识的点进去springframework.boot,可以看到发生如下改变:

    

    这两个文件夹都变成了当前的时间节点,这也印证了昨天的那个pom的依赖关系,同时进去查看它的内容:

        

    dependencies里面的内容有三项,但是不涉及jar包,再去看看parent文件夹呢?

    同样的只有三个内容,注意到pom文件的大小要比dependencies小很多。  

    我想这下局势就明朗了。

    parent和dependencies为我们做好了依赖的兼容性设置,当前版本(springboot)配什么其他版本的产品(集成产品)。但是它们各自涉及的范围有大小。  相当于一个逆向的装饰器模式吧。 哈哈哈。 我们也能注意到在下面写我们的依赖时,并没有写版本号了。  这也是springboot的一大重要优点:  那就是简化配置。

    然后引入 web启动器依赖:spring-boot-starter-web 

            

    更新之后,发生了如下的改变,首先我的项目依赖变了:

         

   于此同时:IDEA提醒我:

    我想正是因为这些配置文件的改变,所以才将这些文件自动的导入的吧。 随便找一个进去看看发生了什么变化:

    哈哈哈,果不其然。   注意这里有一个变量引用应该是:   $MAVEN_REPOSITORYS$,不出意外的话去环境变量里面应该能找到:

    看样子好像出意外了。 但是理论上应该是有的。  应该是ide或者maven在中间做了个对接转化吧。  对接的对象是:环境变量中maven的目录。   要不然就默认为.m2文件夹,毕竟那也是专门为maven准备的。 

    同时看到这个url前面有个 jar://,它转化的具体不知道是基于什么的,但是xml文件里面的属性参数应该是什么都能写,只要符合它的属性参数定义,也就是符合dtd约束。  就看他拿到这个属性值怎么解析了。 所以这里可以不纠结。 

    同时,它这里至少指明了三个信息:  字节码文件路径;  源代码文件路径;   文档路径。因此我们可以看源码。  因此我们写dtd约束的时候它不会飘红。 因此我们可以在运行时只编译自己所写的文件便可以依赖它们运行。 

    接着看看.m2文件发生了什么变化:(同时注意到:上面的那个$MAVEN_REPOSITORYS$应该默认指“C:\Users\14394\.m2\repository”)

    

    但是有一些文件和文件夹,如:spring-beans,等就没有更新。   通过一番对比分析:

        结局也显而易见了:   对于本地的jar依赖包,它会首先检查,没有的就去仓库里面下,有的就直接引进来,自然文件目录中的文件信息就没有发生变动了。   至于为什么有些变了,有些没变,这是根据parent和denpendencies中的版本关系来的,存在springboot版本变了,但是spring的版本没变,或者其他如tomcat版本没变的情况。 

        最后,我还想去看看这些个启动类,以及它们的pom。瞅瞅嘿嘿:

    

        这个<main.basedir,感觉不简单。同时注意到,这个依赖包中并没有包含字节码文件,只有一些配置信息。是不是所有的启动器都是这样的呢??

        分析时候,发现六界之外的奇葩一枚:

    

    六界之外,是因为它并没有加入到依赖目录中。  奇葩是因为,它里面记录了很多产品的启动器的信息。程序是如何将依赖目录中的启动器加载到的呢?  当我们要解耦的时候应该去如何安全的将某一个产品精确的剔除出去呢?  继续看:

    

    好像有些眉头了,继续验证:

    

    道生一,一生二,二生三,三生万物。   我想不用看了,就是这同样的,那么这些配置文件做了什么事情呢?  从稍微熟悉点的tomcat看吧,embed:嵌入,内嵌。  那就去瞅瞅 内嵌tomcat的启动流程:

    

    略加分析,可以去tomcat-embed-core了:

    

    常规的jar包结构,继续:

    

    这两个是比较关键的,直觉告诉我。  它们的包名为: org.apache.catalina.startup

    除了一些它内部的一些结构组成,没有什么有价值的发现。 

    但是去看其他的三个依赖,更加是不会有什么发现的了。 这个时候怎么办呢?是不是思路错了?   回想一下springboot的Enableautoconfigurate的作用:网友所提出的,对于准确性不清楚,但是至少提供了一种参考。 

          

    这里就是那啥约定优于配置吧。 

    在查找资料同时,注意到了一个问题,这里用tomcat来看还不是很好,因为springboot本身就是主要针对web开发的,所以它与servlet具有了一定的耦合性。  注意到大牛写的springboot启动解析:

    到这里,就明白了,springboot做的可不仅仅是将版本兼容性匹配的问题哦。 之所以能够独立运行,无代码生成和xml配置,后面可是做了很多高明的,智能的控制哦。    并不是简单弄弄依赖啥的。 哎,学海无涯,兴趣作舟,千锤百炼,终苦尽甘来。

    贴下大牛地址: http://www.cnblogs.com/saaav/p/6323350.html

阅读更多
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页