176-ContextLoaderListener

好，那我们现在呢，咱们是spring spring VC，还有买杯体这三个框架呢，咱们就都讲完了，那下面的呢，我们就可以来实现一个SSM整合。好，然后首先呢，大家需要来想一个问题，就是咱们的每一个框架，然后在我们SSM整合中所担任的角色，就比如说咱们的spring VC，它是一个表述层框架，然后它能解决的问题啊，其实就是来处理。我们浏览器发送到服务器中的请求，然后并且呢，将一些数据来响应到浏览器，OK吧，好，然后my be呢，它是一个持久层框架，那所以说它的作用就是帮助我们来连接数据库，访问数据库，操作数据库中的数据。而咱们的spring呢，然后它是一个整合型框架，然后呢，所以说它可以使用它的两个核心叫做IOC和AOC，通过IOC来管理对象，比如说咱们my bet里面操作数据库的circle session对象，咱们就可以直接交给spring来进行管理，对不对？好，然后呢，当然我们再通过my be操作数据库的过程中，我们如果要想实现事务功能，那我们是不是也可以来使用spring中a op的一个重要应用，叫做声明式事物来实现，OK吧，行，那我们现在呢，咱们需要来考虑的一个问题是什么呢？就是说我们my be，咱们可以交给spring来进行整合，来进行管理，那我们的spring和spring VC呢，他们两个本身就是同源的，都是属于咱们spring家族的一个框架，那所以说咱们的spring和spring VC这两个需不需要来进行整合呢？大家注意啊，你整合不整合都行。

那我们所说的不整合，就是说把咱们就是我们的spring VC和咱们的spring，然后来创建同一个IOC容器。而我们当前咱们的IOC容器是需要加载咱们spring的配置文件，然后来进行创建的，对吧？然后所以说我们现在就是要把所有的内容呢，都配置到同一个配置文件中，当然呢，咱们也可以配置到多个里面啊好，然后但是我们说的不整合，主要就是让spring mvc和spring来创建同一个IOC容器。

那咱们所说的整合，就是他们各自来管理各自的组件，比如说咱们的spring VC来创建他自己的IC容器，来管理他管理的组件，然后我们的spring呢，然后就把咱们其余的一些组件呢，来进行管理，来创建一个新的IOC容器。其实这两种方式呀都行，但是我们还是建议大家呀，然后把他们两个给整合一下。就是说让我们两个这两个框架，然后来管理他们各自的一些组件就可以啊。好，然后呢，下面呢，我们再继续来进行分析，对吧？然后呢，大家想我们之前咱们在学习spring的过程中，我们所创建的IOC容器，咱们创建IOC容器的这个代码，它都是我们自己写的，对不对，对吧？然后我们每一次咱们去测试的时候，咱们都要获取一个IOC容器，获取完之后，然后来获取我们的B，然后咱们再去操作这个B。

然后但是呢，我们现在咱们创建的是一个外部工程，我们之前咱们用的是一个Java工程，Java工程里面我们可以去控制咱们代码的执行，对吧，咱们写一个测试类，咱们一执行就可以创建一个IOC容器。而我们现在咱们在外部应用里面，那大家说我们创建IOC容器的代码，咱们应该写到哪呢？既然我们现在咱们VC创建一个IOC，我们的spring呢，也要创建一个IOC容器，对吧？那现在那我们spring VC的IC容器是在dispatch solve进行初始化的过程中来创建的，这个咱们之前看源码的时候都看过啊，那咱们的spring的IOC容器该在什么时候创建呢？大家想一下。好，那我们的spring VC呢，咱们从咱们的这个，比如说咱们就从我们组件的依赖关系上，然后进行分析啊，首先咱们spring VC它来管理的组件呢，是咱们的控制层组件。

而我们其他的组件，咱们就要交给来管理，比如比如说咱们的业务层组件service，对吧，就要交给spring来进行管理。而我们当前spring mvc呢？大家想它的控制层，然后是不是依赖于我们当前的service层组件？因为在我们的控制层里面，咱们需要去创建一个service的成员变量，然后呢来进行一个自动装配，然后呢，我们就可以在control里面来使用service对象了，那大家说这个过程是什么时候完成的？咱们的自动装配，咱们之前在讲spring的时候就说过，它是在我们获取IOC容器的时候完成的，那也就是说呀，那我们当前咱们的controller里面来自动装配service这个组件就是在我们当前咱们spring VC的IOC容器获取的时候来执行的，来完成的。对吧？那spring VC的IOC容器什么时候完成的啊，这个spring VC的IOC容器是什么时候创建的，是在dispatch solve进行初始化的时候创建的，对不对？而我们当前咱们的dispatch solve我们在注册的时候，咱们在web的叉ML中去配置的时候，我们加入了一个load on up标签，对吧？好，那所以说大家想想，那我们dispatch of的初始化，然后是不是就是在服务器启动的时候完成的？

对不对？而我们现在呢，大家看我们当前咱们的spring VC它的IC中呢，然后是不是有control t l，然后我们当前咱们的spring的IC容器中是不是有service，然后既然我们当前咱们在获取spring VC的C的时候，就要来完成controller里面的service的自动装配，那也就是说它是依赖于它的，那也就是说在我们获取spring VC的IOC容器的时候，Spring的IOC容器是不是一定要提前创建，那这个时候我们在获取它的IOC容器的时候，才能完成control里面service的自动装配，大家说对不对？

大家想嘛，咱们要想来完成自动装配，IOC容器中是不是必须得有一个类型匹配的B，或者说呢，咱们by type by name的方式都行，但是你必须得有这个病。这个大家能听懂吧，好，那所以我们在获取spring VC的IC容器的时候，我们要想为control里面的service进行自动装配，那我们service类型的病一定是提前存在于我们的IOC容器中的，也就是说我们spring的IOC容器它的创建时间一定要优先于spring VC的IC容器的创建，这个答案能听懂吧，因为它依赖于，那所以说我们在通过controller来获取访问咱们的service进行自动装配的时候，那它的IOC容器一定是提前已经存在好的，对不对，提前创建好的。能听懂吧，好，OK，而我们spring VC的IC容器是什么时候来创建的？咱们刚才说了是在dispatch solve进行初始化的时候创建的，那所以我们当前spring的IC容器的创建是不是一定要在dispatch solve初始化之前？

是不是，那这个时候我们要把咱们创建spring的IOC容器的这个这些代码给放在哪呢？大家想一下。好，然后那我们就需要来考虑一个问题，就是说我们之前咱们在讲咱们这个服务器中的三大组件的时候，就是咱们的solvele filter，还有listener的时候啊，然后咱们说过这三个组件它们的一个执行顺序，首先呢，咱们的监听器呢，大家注意它是最早被执行的，然后第二个是咱们的过滤器，然后第三个呢是light，其实这个很好理解，比如说咱们的监听器啊，咱们用的比较多的就是我们的solve context listener，对吧，它是用来减轻我们当前solve context的状态的。

然后里面有两个方法，然后一个是谁呀，叫做solve contest初始化的方法，然后一个是咱们的solve contextest销毁的方法，然后这个监听器大家注意，它里面的初始化方法是只要监听到服务器启动，那这个初始化的方法就会执行，它是最早执行的一个方法啊好，而我们的过滤器的初始化方法呢，然后执行的也要比咱们solve要早，因为过滤器它可以干什么，它可以来过滤我们当前的目标资源，而咱们的solve就是服务器中的一个资源，所以说solve的初始化时间要比我们这个过滤要比咱们的solve的啊，这个filter的这个初始化时间要比咱们solve的初始化时间要早，然后那所以说我们当前SPAVC的IC容器是在solve的初始化中来执行的，是在我们服务器启动之后solve的初始化方法中执行的，那所以说我们是不是就可以把咱们当前获取。

BIOC容器的代码放在咱们过滤器的初始化方法中，或者说是咱们当前监听器的初始化方法中，对不对？大家想一下。这个时候咱们是不是就可以保证在我获取spring VC的IOC容器的时候，然后我们spring的IOC容器一定是提前创建好的，那咱们是不是就可以来完成controller里面的service的自动装配了，对吧？好啊，那我们现在咱们应该来选择咱们的过滤器还是我们的监听器呢？首先这个过滤器大家要注意，它的功能就是来过滤我们当前的请求和响应，所以说我们一定不能干什么呢？我们我们一定不能说你为了来实现一个功能，就忽略了它最原，它最原始的一个含义，它最原始的一个意义，你的过滤器，大家想，如果我们在初始化的方法中，然后来实现了这个创建spring的IOC容器的代码，那你在过滤的方法中你要写什么呢？直接放行吗？

那你创建这个过滤器，它又有什么意义呢？因为过滤器最主要的功能，咱们初始化的方法你完全可以不写，销毁的方法也完全可以不写，我们最主要来写的就是do filter，对不对？但是现在咱们的do filter没有任何作用，我们只是让它的初始化方法执行了一次，然后从此之后，我们当前的过滤器是不是就会来干嘛，就会来过滤我们当前的请求和响应，而你的过滤器中是没有写任何过滤的代码的，对不对？所以说咱们不能这样去做啊，好，那我们最后呢，咱们是不是就可以来使用这个监听器，这个监听器大家注意，我们的监听器分为三种啊，这个咱们常见的啊就是三种，比如说ideal中帮助我们创建出来的监听器就是三种，第一种叫做solve that contest listen来监听solve that contact状态，然后第二个呢，就是我们的。叫做httb session listener，然后第三个叫httb session attribute listener，后两个呢，都是监听http session的状态的，然后我们用的比较多的呢，就是solve contest来监听solve contest的状态，对不对，对吧？好，然后里边一共有两个抽象方法，第一个抽象方法叫solve contest初始化，第二个。

这个方法叫solve contest销毁，那所以它是不是就是用来监听咱们当前服务器启动，然后还有服务器的关闭，那我们现在要做的任务，大家说不就是在我们服务器启动之后，然后首先来加载spring的配置文件，来获取它的IC容器，然后等到我们SPVC啊，它的IOC容器在获取的时候来完成control里面的service的自动装配。这个大家能听懂吧，好，然后所以说我们现在就可以来使用什么呀，来使用监听器，然后来加载spring spring的配置文件，来获取IOC容器，然后这个时候它就可以来完成我们刚才咱们所需要来完成的一个功能。

OK吧，行，当然这个监听器呢，它不需要我们自己去创建啊，因为这个监听器spring已经给我们提供好了，叫做contest loader listener，叫做context的上下文，它加载的一个监听器。OK吧，然后它呢，其实就是一个solve contest listener，然后这样的一个监听器啊，实现了这样的一个接口，好，然后呢，它在我们当前solve contenttest初始化的方法中，就帮助我们来干什么呢？就帮助我们来完成了一个创建spring IC容器的功能，比如说我们可以把咱们的idea打开，然后咱们可以在这呢，然后来搜索一下大家看啊，然后大家会发现这个监听器，对吧，然后呢，它实现了so contest listener。然后我们在这里面，然后咱们可以来找到我们的context initialized，然后这个就是solve context的初始化，大家看这里面他都干了什么，是不是来执行了一个方法叫in web application contest。

啥意思叫做初始化web application content，这不就是咱们的web应用中的IC容器吗？对不对？好，然后现在呢，咱们可以把它给点开，然后点开之后这个过程就是来获取咱们当前的一个IOC容器的。好，然后这大家看一下是不是叫做create web application contest来创建咱们的IOC容器，然后创建完之后大家看这一句话大家应该也认识，叫做solve contest set attribute干什么？当我们的IOC容器创建之后，它会把咱们的IOC容器呢，共享到咱们当前最大的应用育种。然后这个在我们spring VC的IC容器获取的过程中，是不是也实现过相同的代码，对不对，创建完之后把它放在我们最大的预对象里面啊好，这个大家注意，那行，那所以说我们现在咱们是不是就可以干什么，我们就可以通过这个监听器，然后去监听服务器它的一个状态，在服务器启动时，然后直接来创建spring的IOC容器，那我们是不是就可以干什么了？来在spring VC它获取IOC容器的时候，来直接完成自动装配的过程中，对吧，然后来对control里面的service进行自动装配。

这个问题大家一定要想明白啊，为什么在这它用监听器对不对，为啥呀，对吧？首先咱们的监听器里面初始化的方法，它只执行一次，我们在获取IOC容器的时候，你没有必要说我每一次咱们都得，我每一次使用它，我都得需要重新获取吗？大家说需要吗？完全没有这个必要。我们是不是只需要干什么呢？因为大家想我们创建IOC容器，大家都是通过配置文件创建出来的，对吧？那你通过同一个配置文件创建出来的IOC，它有什么样的区别吗？没有区别呀，对吧，咱们这里面管理的并都是一样的，所以说我们的IOC容器你需要创建多次吗？没有必要，咱们只需要创建一次就行。

能听懂吧，好，所以说咱们，而且咱们的监听器呢，它的初始化方法是不是在服务器启动之后第一个执行的方法，对吧，它是要比我们当前咱们的dispatch solve初始化时间要早的，对不对，那我们是不是就可以通过监听器创建spring它的一个IOC容器来完成，然后当我们的dispart service进行初始化的时候，咱们就可以完成control里面的service的自动装配了，对不对，好啊。行。那当然了，那我们要想来使用这个监听器的话，那大家都知道监听器它是不是必须得干什么，在我们的web点叉L中来进行配置，那咱们怎么配置呢？大家可以通过这个标签，就是listener标签对吧？Listener标签然后把我们当前咱们的监听器的全类名。配置到咱们当前的listener class中。好，然后配置完之后呢，大家想，那既然咱们的监听器里面，然后咱们通过spring的配置文件获取IOC容器的代码都是别人写好的。

对吧，那所以说spring的配置文件的名字人家是不是已经规定好了呀，这个位置是不是也是人家已经规定好的，大家说是不是对吧，因为人家的代码人家都已经写死了嘛，是不是好，然后呢，所以说spring的配置文件咱们应该放在哪呢？大家注意它默认的位置和名称啊，是在外部银for下，名字叫做application contest的长L。这也是为什么我们第一次咱们在讲spring的时候，我们给大家创建的spring的配置文件就叫这个，对不对，对吧？好，然后再往下，那当然我们也可以去自定义spring配置文件的位置和名称，就像咱们的spring m VC一样，但是呢，大家注意，我们spring mvc中咱们使用的是solve的初始化参数，而我们当前咱们需要来使用的是咱们的上下文初始化参数。

其实也就是我们当前工程的初始化参数，知道吧？好，大家看咱们的参数名，同样是叫context的config location一样的，跟咱们去配置SPAVC的一个这个配置文件的位置和名称是一样的啊，然后我们通过class pass将咱们的配置文件的位置设置为类路径，然后再通过咱们spring点叉L，就可以把配置文件的名字来设置为spring的XL。OK吧，行，这个大家注意好，那所以说这就是咱们当前的这个监听器，然后这个监听器的作用大家一定要知道，就是在咱们服务器启动的时候来加载spring的配置文件，来获取spring的IOC容器，OK吧，行啊。