Struts2 Convention plug-in-annotation-based action ing

The new project uses struts2.3.4, the latest version of struts2, and the cumbersome configuration file. Instead, it uses annotation to configure action ing. I have never touched on this knowledge before, recently, I have learned a lot about related knowledge, mostly from online blogs. However, most of my blogs are scattered and not completely correct. What's worse is that you transfer the resources. Although there are many resources, they are similar, it is rare to press the keyboard on your own. In addition to reading this book on blogs, I learned a little about it and wrote it here intermittently to avoid forgetting it.

The Network blog struts2 used codebehind as the zero-configuration plug-in. codebehind was abandoned since struts2.1. Instead, it used the Convention plug-in to support zero-configuration. Compared with codebehind, the Convention plug-in is more thorough. This plug-in can discard the configuration information completely, not only does it need to use struts. you can configure the XML file without using annotation. Instead, it is automatically configured by struts2 according to the conventions (remember that the conventions are better than the configurations ).

The jar package used is struts2-convention-plugin-2.3.4.jar

The jar package of the Convention plug-in has a struts-plugin.xml configuration file, which is configured with a large number of configuration constants, these constants can be rewritten, as long as the struts in our project. overwrite the xml configuration file. The Zero Configuration convention of the plug-in is defined by these constants.

I. Action ing

By default, the Convention plug-in automatically searches for all Java classes in the action, actions, struts, and struts2 packages to find the action, actions under struts2 are mapped to the root namespace. The actions under their sub-packages are organized into corresponding namespaces by package path.
For example, the com. zyh. Action. useraction class is mapped to/user. Action, while com. zyh. Action. User. useraction is mapped to/user. Action.
This is a constant configuration, that is, in the XML file mentioned above, as follows:

<constant name="struts.convention.package.locators" value="action,actions,struts,struts2"/>

When we need to change the package where the action is located, we can change the constant overwrite. Note that if the constant is changed, the ing root path of struts2 will also change.
For example, we overwrite this constant:

<constant name="struts.convention.package.locators" value="test"/>

The action that meets the conditions under the test package is mapped to the root namespace. The action under the sub-package organizes the namespace according to the package path. For example
Com. zyh. Test. useraction is mapped to/user. Action, and COM. zyh. Test. User. useraction is mapped to/user. Action, and so on.
By default, the search result uses the following two types of actions as struts2:
1) Implement the Action interface or inherit the actionsupport class.
2) classes ending with actions (such as useraction ). This is also configurable, as shown in the Struts. plugin. xml file:

<constant name="struts.convention.action.suffix" value="Action"/>

That is to say, even if our class does not implement the Action interface or inherit the actionsupport class, it can also be used as the action of struts2. However, it should be noted that, I have not found any explanation of this problem on the network. During my experiment, a common class ended with an action suffix (the Action interface is not implemented or the actionsupport class is inherited) it cannot always be mapped to action. It is conditional, that is, the class should have an execute method. If not, it cannot be recognized by the Convention plug-in.

I don't know whether this conclusion is authoritative. I also saw an introduction to the experiment. I wrote a common class ending with an action, but it never could be mapped to an action, later, I copied a class of another project (only one more execute method than the former), but it can be mapped. Therefore, it is concluded that it remains to be verified.

Ii. config-browser plug-in

Speaking of this, it is recommended that another plug-in struts2-config-browser-plugin-2.3.4.jar struts2, with it can be very convenient to view their own project action ing, the use is very simple, copy the jar package to the project class path, after starting the server, enter:

Http: // localhost: 8888/Application name/config-Browser/index. Action

You can view constant configuration, namespace, Action ing, and other information.

Iii. Action name

Follow the following rules when ing the name of an action:

1) if the action class name contains the action suffix, remove the action Suffix of the action class name; otherwise, no processing is performed.

2) convert the camper of the action class names (the first letter of each word is written in uppercase and the other letters are written in lowercase) into a line-to-line (all letters are in lowercase and words are separated from a line-to-line)

This can also be configured as follows:

<constant name="struts.convention.action.name.separator" value="-"/>

Example: The name attribute of the acion mapped by loginaction is login, the name attribute of the Action mapped by getbooks is get-books, and the name attribute of the Action mapped by addemployeeaction is add-employeet.

The ing method uses an exclamation point! Is specified after the action name! + The method of method name is used to specify the access method. For example, the userloginaction login method should be like user-login during access! Login. Action.

Iv. Conventions for returning view resources by Action

By default, Convention always locates physical resources in the WEB-INF/content path of the Web application. The Convention for locating resources is: actionurl + result_code + suffix. When a logical view cannot find the corresponding resource, convention automatically uses actionurl + suffix as the physical view resource.

For example, when actions. Fore. loginaction returns the success string, Convention takes precedence over using the WEB-INF under the login-success.jsp/content/Fore directory as the view resource. If the file cannot be found, login. jsp can also be used as the corresponding resource. If an input string is returned, Convention looks for the WEB-INF in the login-input.jsp/content/Fore

The definition of view resource location can also be found in the struts-plugin.xml, the default definition is as follows:

<constant name="struts.convention.result.path" value="/WEB-INF/content/"/>

We can also overwrite this definition so that it can search for view resources in the specified path.

A lot of things are complicated to say, but they are easier to understand. The Convention plug-in of struts2 is also complicated. Just remember this and try again when you are free...