Springフレーム学習(二):Springアプリケーション配置ファイル解析
12452 ワード
[TOC]
Springフレーム学習(二):Springアプリケーション配置ファイル解析
Springを初めて習った時は、猫の虎を見ただけで、配置の由来はよく分かりません.ここで、これらの構成がどのような役割を果たしているかを深く理解してみましょう.
web.xml
アプリケーションが起動すると、Tomcat容器からweb.xmlのプロファイルが読み込まれます.正常なweb.xmlの例は以下の通りです.
servletノードは、HTTP要求を処理するHttpServlet実装クラスを構成するために使用され、具体的にどのような要求を処理するかは、servlet-mappingに配置されている.Displatch ServletはMVCモードのコントローラで、配信要求を担当しています.すべてのWeb要求は、それによって処理され、転送、マッチング、データ処理を行った後、ページによって表示される.初期化時にcontextConfigLocationパラメータ設定のファイルを解析し、MVCサブ容器を作成します.
filterノードはフィルタFilterを構成し、HTTP要求に対してフィルタ、チェック、ログ監視記録の作業を行うことができ、具体的に適合する要求urlはfilter-mappingノードに配置される.
appication Contect.xml
Contect Loader Listenerは、Spring容器を初期化するために、appication Contact.xmlファイルを解析します.一般的な構成例は以下の通りである.
「Spring技術の内幕」では、「IOC容器はまず両親の文脈からgetBeanに行く」と述べていますが、これは私たちの日常のプログラムの感じと違っていますので、とりあえず父の容器に行ってbeanを取るか、それとも子供の容器に行ってbeanを取るか、やはりソースを深く見てみましょう.Application ComptextのgetBen方法はAbstractAplication Contect類で実現されます.
spring mvcサブ容器初期化依存mvc.xmlは、このファイルの具体的な名前はDisplatch Servletと一緒に配置されたパラメータです.
まとめてみますと、mvc.xmlに保存されているのは基本的にHTTP要求の処理に関する構成です.
参考資料 XMLドキュメントのxmlns、xmlns:xsi、xsi:schemaLocation について
Springフレーム学習(二):Springアプリケーション配置ファイル解析
Springを初めて習った時は、猫の虎を見ただけで、配置の由来はよく分かりません.ここで、これらの構成がどのような役割を果たしているかを深く理解してみましょう.
web.xml
アプリケーションが起動すると、Tomcat容器からweb.xmlのプロファイルが読み込まれます.正常なweb.xmlの例は以下の通りです.
contextConfigLocation
classpath:spring/applicationContext.xml
org.springframework.web.context.ContextLoaderListener
org.springframework.web.context.request.RequestContextListener
spring
org.springframework.web.servlet.DispatcherServlet
contextConfigLocation
classpath:spring/mvc.xml
1
spring
/
default
*.css
default
*.gif
default
*.jpg
default
*.js
default
*.html
http_filter
com.xxx.HttpFilter
http_filter
/api/search.json
context-paramノードに格納されたキーパッドのペアはServlet Conteetに保存されます.その後、そのget Init Parameterを通じてその値を得ることができます.ServletContext sc;
String configLocationParam = sc.getInitParameter("contextConfigLocation");
listenerノードに保管されているContect LoaderListene類はインターフェースServlet Contact Listenerを実現し、Web容器の初期化と閉鎖を監督し、相応の初期化と廃棄作業を行う.public interface ServletContextListener extends EventListener {
void contextInitialized(ServletContextEvent var1);
void contextDestroyed(ServletContextEvent var1);
}
Spring容器はContect LoaderListenerのcontext Initializedメソッドで初期化されます.public class ContextLoaderListener extends ContextLoader implements ServletContextListener {
public void contextInitialized(ServletContextEvent event) {
this.contextLoader = this.createContextLoader();
if(this.contextLoader == null) {
this.contextLoader = this;
}
this.contextLoader.initWebApplicationContext(event.getServletContext());
}
}
listenerノードに格納されているもう一つのクラスのRequest Contect ListenerはインターフェースServletRequest Listenerを実現し、毎回HTTP要求を傍受し、管理作用領域はRequestのbeanである.作用域がrequestであるbeanは、要求が入った時に作成され、終了時に廃棄されます.public interface ServletRequestListener extends EventListener {
void requestDestroyed(ServletRequestEvent var1);
void requestInitialized(ServletRequestEvent var1);
}
このうちContect Loader Listenerは必須であり、Request Contactext Listenerは任意である.servletノードは、HTTP要求を処理するHttpServlet実装クラスを構成するために使用され、具体的にどのような要求を処理するかは、servlet-mappingに配置されている.Displatch ServletはMVCモードのコントローラで、配信要求を担当しています.すべてのWeb要求は、それによって処理され、転送、マッチング、データ処理を行った後、ページによって表示される.初期化時にcontextConfigLocationパラメータ設定のファイルを解析し、MVCサブ容器を作成します.
filterノードはフィルタFilterを構成し、HTTP要求に対してフィルタ、チェック、ログ監視記録の作業を行うことができ、具体的に適合する要求urlはfilter-mappingノードに配置される.
appication Contect.xml
Contect Loader Listenerは、Spring容器を初期化するために、appication Contact.xmlファイルを解析します.一般的な構成例は以下の通りである.
なぜcomponent-scanの中でexcludeにControllerを落とすべきですか?これはSpringコアモジュールがHTTP要求を処理していないためで、HTTP要求を処理するのはSpring MVCサブモジュールで、両者は異なる容器を使用しています.Controller注解のbeanはmvc容器の中で作成しなければ機能しないので、親容器の配置から除外します.「Spring技術の内幕」では、「IOC容器はまず両親の文脈からgetBeanに行く」と述べていますが、これは私たちの日常のプログラムの感じと違っていますので、とりあえず父の容器に行ってbeanを取るか、それとも子供の容器に行ってbeanを取るか、やはりソースを深く見てみましょう.Application ComptextのgetBen方法はAbstractAplication Contect類で実現されます.
public abstract class AbstractApplicationContext extends DefaultResourceLoader implements ConfigurableApplicationContext, DisposableBean {
public T getBean(Class requiredType) throws BeansException {
return this.getBeanFactory().getBean(requiredType);
}
}
この方法はBenFactoryのgetBean方法を呼び出しています.AbstractBenFactory類のgetBean方法から見て、確かにサブ容器を優先的に使うbeanです. public Object getBean(String name) throws BeansException {
return this.doGetBean(name, (Class)null, (Object[])null, false);
}
protected T doGetBean(String name, Class requiredType, final Object[] args, boolean typeCheckOnly) throws BeansException {
final String beanName = this.transformedBeanName(name);
Object sharedInstance = this.getSingleton(beanName);
Object bean;
if(sharedInstance != null && args == null) {
//
} else {
if(this.isPrototypeCurrentlyInCreation(beanName)) {
throw new BeanCurrentlyInCreationException(beanName);
}
BeanFactory ex = this.getParentBeanFactory();
// containsBeanDefinition false, bean,
if(ex != null && !this.containsBeanDefinition(beanName)) {
String var21 = this.originalBeanName(name);
if(args != null) {
return ex.getBean(var21, args);
}
return ex.getBean(var21, requiredType);
}
// 。。。
}
private final Map beanDefinitionMap = new ConcurrentHashMap();
// DefaultListableBeanFactory
public boolean containsBeanDefinition(String beanName) {
Assert.notNull(beanName, "Bean name must not be null");
return this.beanDefinitionMap.containsKey(beanName);
}
mvc.xmlspring mvcサブ容器初期化依存mvc.xmlは、このファイルの具体的な名前はDisplatch Servletと一緒に配置されたパラメータです.
ここのcomponent-scanでServiceのコメントを削除するなら、排除しないと何か問題がありますか?多くの場合は問題ないですが、もしAOPを使ったら、Serviceの注釈を排除していませんので、Controllerが使っているServiceは父の容器にも現れますし、子の容器にも現れます.しかし、父の容器の中のServiceだけはAOPで処理されます.しかし、Controllerは同じ容器のServiceを優先的に使います.その結果、AOPで代理されていないサービスが呼び出されます.まとめてみますと、mvc.xmlに保存されているのは基本的にHTTP要求の処理に関する構成です.
参考資料