When struts2 is used alone, the Action instance is created by struts2 itself; when struts2 is integrated with spring, the Action instance is created by spring. This results in a slight difference in the configuration of the struts.xml configuration file in the two cases. The default implementation of Struts2 is the prototype mode (the prototype mode among the 23 design modes), which means that each request will generate a new Action instance, so there is no thread safety issue. It is important to note that: by default in spring, the scope is a singleton mode, that is, scope="singleton", which only creates one Action instance. The consequence of this is that each access is the same Action instance, and the data is not the same. Safety. Therefore, if the life cycle of Action is managed by spring, the scope should be configured as the prototype scope, that is, scope="prototype". Configure in spring's applicationContext.xml configuration file such as:
<!-- action configuration-->
<bean id="testAction" class="com.study.action.TestXxxAction" scope="prototype">
<!-- action injection-->
<property name="xxx" ref="xxx" />
</bean>
Scope scope In addition to prototype and singleton, there is another scope: session. If the scope is set to scope="session", it will help to avoid the concurrency problem of actions in the web, because the bean instance is only created once for the current user until the session disappears. In this case, for the current user, the bean is stateful, and the advantage is that fewer instances of the bean are created, and there is a little performance improvement.
Application scenarios:
1. Prototype should be used in most cases;
2. If there are not many users and frequent operations (frequent use of actions), and the hardware is average, you can consider session, and maybe improve the performance a little (not really tested).
1. When struts2 is used alone, the class attribute of the action in the struts.xml configuration file is the full path name of XxxAction, and the configuration in the struts.xml configuration file is as follows:
<action name="xxx"class="com.study.action.TestXxxAction"> <result>/test/showXxxTest.jsp</result> </action>
2. When struts2 is integrated with spring, the class attribute of action in struts.xml is the id attribute value of the bean configured in the spring configuration file applicationContext.xml, as follows:
<!-- action configuration-->
<bean id="testAction" class="com.study.action.TestXxxAction" scope="prototype">
<!-- action injection-->
<property name="xxx" ref="xxx" />
</bean>
<action name="xxx"class="testAction"> <result>/test/showXxxTest.jsp</result> </action>
When the struts2-spring-plugin-2.xxjar plugin generates an action instance, it will automatically inject the action attributes according to the name, even if it does not inject attributes for the relevant action (bean) in the spring configuration file (applicationContext.xml) or Using annotation injection in the action class, it will also find out whether there is a bean corresponding to this name in the current container (Spring) according to the name of the attribute in the action class and inject it, or inject it with a given name displayed. So the id of the action (in the spring configuration file applicationContext.xml) should not be the same as the variable name in this class. If the class of the action configured in the struts.xml file is the actual class that points to the action, then the generation of the action is controlled by struts, and the relevant variables in the action class will inject a corresponding bean from the container according to the name. For the bean with the corresponding name, once this action is called, an error will occur. But if you add a @Resource annotation to the variable at this time, after the struts container has generated an action, it will find the corresponding bean injection from the Spring container. If the class points to a pseudo controller (the bean corresponding to the action in the applicationContext of the spring configuration file), then the generation of the action is controlled by spring. At this time, the relevant variables in the action class must be injected into the corresponding bean by annotating @Resource or xml, unlike before, the injected bean will be automatically searched from the spring container according to the name, otherwise the program will run incorrectly.
To put it simply, it should be controlled by the struts-spring-plugin plug-in or by the spring container, controlled by the plug-in, then the Action instance is generated by the plug-in, and the automatic assembly function of the spring container is started to automatically assemble the required business components. into the Action instance. In this strategy, spring is only responsible for managing dependencies. Advantages: Simple configuration. Disadvantages: 1. The coupling between Action and business components has been reduced to the code level, and the attribute name in Action is required to be consistent with the id of the business component in the configuration file, and the coupling is high. 2. Automatically assembled by spring, the dependencies are unclear and the readability is poor. The second is controlled by the spring container. The Action instance is regarded as a common bean instance, and the default value of the scope needs to be changed. The class attribute of Action in struts.xml corresponds to the id of an Action instance in the spring container. Advantages: A high degree of decoupling is achieved. Disadvantages: 1. The configuration file is redundant and bloated. Not only do you need to configure the action information in struts.xml, you also need to configure the action information in the spring configuration file.