Struts and spring integration first need to automatically assemble the ApplicationContext configuration information when the Web container is started. You can imagine that the corresponding configuration should be made in web. xml:
[Html]
<Context-param>
<Param-name> contextConfigLocation </param-name>
<Param-value>
Classpath: applicationContext. xml
</Param-value>
</Context-param>
<Listener>
<Listener-class> org. springframework. web. context. ContextLoaderListener </listener-class>
</Listener>
After org. springframework. web. context. ContextLoaderListener is configured, we will not hesitate to compile code to display and instantiate the ApplicationContext object. The reason for listening is that the loading sequence of web. xml is context-param-> listener-> filter-> servlet. If you do not want to use the listener, you may try to inherit the org. apache. struts2.dispatcher. ng. filter. strutsPrepareAndExecuteFilter override this init method to instantiate the ApplicationContext object in the StrutsPrepareAndExecuteFilter filter init to load configuration information. Although this method is also feasible, every action is intercepted to load configuration information once, re-instantiate a new web container, which not only wastes resources but also makes spring more dependent on struts.
1. xml:
Struts2 Configuration
<Package name = "user" extends = "struts-default">
<Action name = "login" class = "userAction">
<Result name = "success">/success. jsp </result>
<Result name = "input" type = "redirect">/index. jsp </result>
</Action>
</Package>
Spring Configuration
<Bean id = "userDao" class = "org. han. dao. impl. UserDaoImpl"/>
<Bean id = "biz" class = "org. han. service. impl. LoginBizImpl">
<Property name = "userdao" ref = "userDao"/>
</Bean>
<Bean id = "userAction" class = "org. han. action. LoginAction" scope = "prototype">
<Property name = "biz" ref = "biz"/>
</Bean>
Note that in the red part, the action class of struts2 must be the same as the corresponding action bean, so that the action can be managed by spring;
2. Use the zero configuration method of struts2:
When importing a zero-configuration plug-in package, you must note that the conventions are greater than the configuration, or the above spring configuration, but you do not need to configure struts2.
Method 1: You only need to map the Action className to the bean id in spring configuration.
@ Action (value = "/login", results = {@ Result (name = "success", location = "/success. jsp "), @ Result (name =" input ", location ="/index. jsp ")}, className =" userAction ")
Public String login () throws Exception {
// TODO Auto-generated method stub
User u = biz. login (this. getUser ());
If (u! = Null ){
Return SUCCESS;
}
Return INPUT;
}
Method 2:
The Action annotation does not require className, and the spring configuration is slightly modified.
<Bean id = "org. han. action. LoginAction" class = "org. han. action. LoginAction" scope = "prototype">
<Property name = "biz" ref = "biz"/>
</Bean>
This can be because when you use zero configuration, the action class defaults to the full class Name of the current class, when integrating with spring, you can use the full class name to search for the bean with the full class name id in spring configuration.
3. struts2 and spring all use annotation methods:
Www.2cto.com
<Beans xmlns = "http://www.springframework.org/schema/beans"
Xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance"
Xmlns: context = "http://www.springframework.org/schema/context"
Xsi: schemaLocation = "http://www.springframework.org/schema/beans
Http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
Http://www.springframework.org/schema/context
Http://www.springframework.org/schema/context/spring-context-3.0.xsd>
<Context: component-scan base-package = "org. han. dao. impl, org. han. service. impl, org. han. action"/>
</Beans>
<Context: component-scan base-package = ""/> in this way, you do not need to configure the bean in the configuration file or import the corresponding processing bean. In other words, you do not need to use <context: annotation-config/> in the configuration file, because this method will automatically import
[Java]
@ Namespace ("/")
@ Component (value = "userLogin ")
@ Scope (value = "prototype ")
Public class LoginAction extends ActionSupport {
Public LoginAction (){
Super ();
// TODO Auto-generated constructor stub
System. out. println ("action:" + this. hashCode ());
}
@ Autowired
Private ILoginBiz biz;
Private User user;
Public User getUser (){
Return user;
}
Public void setUser (User user ){
This. user = user;
}
@ Autowired
Public void setBiz (ILoginBiz biz ){
This. biz = biz;
}
@ Override
@ Action (value = "hello", results = {@ Result (name = "success", location = "/success. jsp "), @ Result (name =" input ", location ="/index. jsp ")})
Public String execute () throws Exception {
// TODO Auto-generated method stub
System. out. println ("biz:" + this. biz. hashCode ());
User u = biz. login (this. getUser ());
If (u! = Null ){
Return SUCCESS;
}
Return INPUT;
}
}
@ Component has an optional input parameter used to specify the Bean name. In general, beans are all singleton. To inject beans, you only need to use the byType policy to automatically inject them. Therefore, you do not need to specify the Bean name. In addition to providing @ Component comments, several comments with special semantics are defined: @ Repository, @ Service, and @ Controller. In the current Spring version, the three annotations are equivalent to @ Component, but from the annotation class name, it is easy to see that the three annotations correspond to the persistence layer, business layer, and control layer (Web layer) respectively. Although these three annotations are not new than @ Component, Spring will add special features for them in future versions. Therefore, if a Web application uses a classic layer-3 hierarchy, we recommend that you use @ Repository, @ Service, and @ Controller to annotate classes in the hierarchy at the persistence layer, business layer, and control layer, and use @ Component to annotate those neutral classes.
@ Scope is used to define the Scope of the Bean.
@ Autowired annotation, which can mark class member variables, methods, and constructors to complete automatic assembly. When the Spring container is started, AutowiredAnnotationBeanPostProcessor will scan all the beans in the Spring container. When the Bean contains @ Autowired annotations, it will find the Bean that matches it (by default, it matches by type, and inject it to the corresponding place. After @ Autowired is used for member variables, you can delete their setter methods.
The name in @ Qualifier ("name") is the Bean name, so when @ Autowired and @ Qualifier are used together, the automatic injection policy is changed from byType to byName. @ Autowired can annotate member variables, methods, and constructors. The annotation object of @ Qualifier is member variables, method input parameters, and constructor input parameters.
@ PostConstruct and @ PreDestroy: The JSR-250 defines two annotation classes for the specified method after initialization/destruction, which can only be applied to methods. The method marked with @ PostConstruct annotation will be called after the class is instantiated, and the method labeled with @ PreDestroy will be called before the class is destroyed.
You can configure the init-method/destroy-method attribute of the <bean> element to specify only one initialization/destruction method for the Bean. However, you can use the @ PostConstruct and @ PreDestroy annotations to specify multiple initialization/destruction methods. The methods marked with @ PostConstruct or @ PreDestroy annotations will be executed during initialization/destruction.
For more instructions, see the official documentation.
4. Conclusion:
1. annotation configuration is not necessarily superior to XML configuration in the previous days. If the Bean dependency is fixed (such as which DAO classes are used by the Service), the configuration information will not be adjusted during deployment, so the annotation configuration is better than the XML configuration; if the dependency is adjusted during deployment, the XML configuration is obviously better than the annotation configuration because the annotation is an adjustment to the Java source code, you must rewrite the source code and re-compile the code to make adjustments.
2. If the Bean is not a self-compiled class (such as JdbcTemplate and SessionFactoryBean), the annotation configuration cannot be implemented. XML configuration is the only available method.
3. annotation configuration is usually similar, while XML configuration can be more flexible. For example, the Transaction configuration using the aop/tx namespace is more flexible and simple than the @ Transaction annotation.
Therefore, in the implementation of applications, we often need to use both annotation configuration and XML configuration. For Class-level configurations that do not change, annotations configuration should be given priority; XML configuration should be preferred for third-party classes and configuration that is prone to adjustment. Spring will combine the metadata of these two configuration methods before Bean creation and Bean injection are implemented.
Author: hanzhou4519