Struts2 plug-in mechanism

Struts2 provides a very flexible extension method. This extension method, called plugin, has the same concept as eclipse or Firefox Plugin, through programs independent of the main body, to expand or enhance the functions of the subject.

Undoubtedly, the extension method of plugin is the most popular and reasonable one. With plugin, you can extend and replace some features in struts2, or you can add your own implementation classes, so that struts2 has new features. The plug-in method also makes any function extension maintain independence from the main program of struts2. This allows anyone to implement their own plug-in as per their own wishes.

Contents [-]

1. All aspects of plugin
2. Common plug-ins of struts2
3. Struts2 extension point

All aspects of plugin Dependency 

Struts2 reference writes plugins are not loaded in any special order. plugins shoshould not have dependencies on each other. A Plugin may depend on classes provided by struts core, but it shoshould not depend on classes loaded by another plugin.

The description taken from the reference of struts2 clearly tells us that the plug-in of struts2 provides additional function support for the main program of struts2. SoPlugin itself is a main program dependent on struts2, That is, struts-core.jar. Of course, plugin for a specific function may have other library dependencies, but these dependencies should never affect the struts2 main program itself. However,Different plug-ins should not form dependencies between each other.

Representation 

Struts2 reference writes a struts 2 plugin is a single jar that contains classes and configuration that extend, replace, or add to existing Struts framework functionality.

Obviously, the plug-in of struts2 exists in the form of a jar package.

Installation and Use 

Struts2 reference writes a plugin can be installed by adding a jar file to the application's class path, in addition to the jar files to fulfill whatever dependencies the plugin itself may have.

If you want to get support for a plug-in, you only need to put the plug-in jar package under classpath, and do not forget the jar package on which the plug-in depends.

Elements 

Struts2 reference writes to configure the plugin, the jar shoshould contain a struts-plugin.xml file, which follows the same format as an ordinary struts. xml file.

Since a plugin can contain the struts-plugin.xml file, it has the ability:

* Define new packages with results, interceptors, and/or actions
* Override framework Constants
* Introduce new extension point implementation classes

Do not be clear. The plug-in requires a file named struts-plugin.xml, which is in the same format as Struts. xml. In this file, you can configure the extension points of struts2 for this plug-in, which contains three different types mentioned above.

Operating Mechanism 

Struts2 reference writes the framework loads its default configuration first, then any plugin configuration files found in others jars on the classpath, and finally the "Bootstrap" struts. xml.

Struts-default.xml (bundled in the core jar)
2. struts-plugin.xml (as alias as can be found in other jars)
3. Struts. XML (provided by your application)

Since the Struts. xml file is always loaded last, it can make use of any resources provided by the Plugins bundled with the distribution, or any other plugins available to an application.

This section is also taken from the reference of struts2, which has already profoundly described how struts2 handles plugin. From here, we can also see that the reason why plug-in can easily expand struts2 itself in the form of a jar package, the core reason is that struts2 loads all its own and plugin configuration files at system startup, and determines what features struts2 has at runtime based on these configuration files.

From these words, we can also find many things:

1. The struts-core.jar located inside the struts-default.xml package is always loaded first to ensure that struts2 has many default behavior methods.

2. All plug-ins are equal to each other, so there should be no dependency between them. At the same time, there is no specific order for struts2 to load the plugin configuration files when the system starts.

3. struts2 will finally load a file named struts. xml under your own program classpath. Therefore, I have seen a lot of friends on the forum asking questions like this, which can be easily solved:

1) is the default configuration file of struts2 only called "struts. xml "? ----Yes 
2) is the default configuration file of struts2 only available in the root directory of classpath? ----Yes 

However, struts2 provides a complete configuration file management mechanism. in XML, the extends method is used to define any configuration method that you need to overwrite its default behavior. Of course, you can also separate the configuration files by using import and other methods.

The common plug-in struts2 reference of struts2 writes that they are both popular but optional features of the framework are distributed as plugins. an application can retain all the Plugins provided with the distribution, or just include the ones it uses. plugins can be used to organize application code or to distribute code
To Third-parties.

According to the instructions in the reference of struts2, many common struts2 extension functions are implemented through plugin, and these common plugins have been contributed by many predecessors, as part of the distribution package of struts2, you can find these plugins and their source code in the release package of struts2.

Of course, you can also implement your own plugin. Many struts2 plug-ins are not hosting on Apache, but in the list of Apache plug-ins, we can find them:

Http://cwiki.apache.org/S2PLUGINS/home.html

Many programmers may be overwhelmed by these complicated plug-ins. So here I have made a simple classification of plugin and listed some typical plugins for you to learn:

1. framework integration

This type of plugin provides the integration of struts2 with many other open-source frameworks. Therefore, those who asked me on the forum how to integrate struts2 and spring and how struts2 and DWR. Let's take a look at the descriptions of these plug-ins and try to run the examples of these plug-ins, maybe you will have a lot of GAINS.

Spring Plugin: http://cwiki.apache.org/S2PLUGINS/spring-plugin.html

Guice Plugin: http://cwiki.apache.org/S2PLUGINS/guice-plugin.html

Jruby Plugin: http://cwiki.apache.org/S2PLUGINS/jruby-plugin.html

2. Simplified configuration class

The main purpose of this type of plug-in is to simplify the original configuration structure of struts2, which may include omitting the xml configuration using COC, so that struts2 supports restful and so on. However, many of these plug-ins involve the underlying internal implementation of struts2, so please choose carefully when using it.

Codebehind Plugin: http://cwiki.apache.org/S2PLUGINS/codebehind-plugin.html

Smarturls Plugin: http://cwiki.apache.org/S2PLUGINS/smarturls-plugin.html

Convention Plugin: http://cwiki.apache.org/S2PLUGINS/convention-plugin.html

3. Page Decoration

This type of plug-in is easy to say. It aims to integrate a framework similar to tiles or sitemesh and provide a good page structured environment integration.

Sitemesh Plugin: http://cwiki.apache.org/S2PLUGINS/sitemesh-plugin.html

Tiles Plugin: http://cwiki.apache.org/S2PLUGINS/tiles-plugin.html

4. Function extensions

This type of plugin is the most abundant, including a variety of additional function extensions, for example, jfreechart is integrated for chart integrated output, open flash chart for flash style report output, and jasperreport for PDF output.

Jfreechart Plugin: http://cwiki.apache.org/S2PLUGINS/jfreechart-plugin.html

Jasperreports Plugin: http://cwiki.apache.org/S2PLUGINS/jasperreports-plugin.html

Connext graph Plugin: http://cwiki.apache.org/S2PLUGINS/connext-graph-plugin.html

In the subsequent sections, I will select several representative in INS for detailed analysis and description. The extension points of struts2 show that many default behaviors of struts2 can be extended through plugin. So what actions can struts2 expand? In struts2, how does one support these extensions?

According to my understanding, I divided the scalability of struts2 into three types:

1. Customize interceptor and result to expand the running program 

The custom interceptor and result are very simple. You only need to implement the xwork interceptor interface and result interface respectively. Then, define these Implementation classes in your struts. xml so that they are loaded by struts2 by default. For interceptor, you may need to pay special attention to its position in the entire interceptor stack.

This type of extension does not involve the internal running mechanism of struts2, but only changes the operation mode and structure of the action. Therefore, this type of extension belongsApplication-level Scaling.

2. Override static variables of struts2 

Many static variables are defined in struts2, which define many default behaviors of struts2. These static variables can be defined in different ways. The following example from the struts2 reference demonstrates defining these static variables in different files.

This is defined in struts. xml: Java code

1. <Struts>
2. <Constant name = "struts. devmode" value = "true"/>
3. ...
4. </Struts>

This is defined in struts. properties: Java code

1. Struts. devmode = true

This is defined in Web. xml: Java code

1. <Web-app id = "webapp_9" version = "2.4"
2. Xmlns = "http://java.sun.com/xml/ns/j2ee"
3. Xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance"
4. Xsi: schemalocation = "http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
6. <Filter>
7. <Filter-Name> struts </filter-Name>
8. <Filter-class> org. Apache. struts2.dispatcher. filterdispatcher </filter-class>
9. <Init-param>
10. <Param-Name> struts. devmode </param-Name>
11. <Param-value> true </param-value>
12. </Init-param>
13. </Filter>
14. ...
15. </Web-app>

All these definitions are accepted by struts2 and used as parameters to change the default behavior of struts2. However, when struts2 is started, it Loads files in a certain order.

Struts2 reference writes constants can be declared in multiple files. By default, constants are searched for in the following order, allowing for subsequent files to override previous ones:

1. struts-default.xml
2. struts-plugin.xml
3. Struts. xml
4. Struts. Properties
5. Web. xml

The reference of struts2 tells us that struts2 loads the values of all static variables in the above order by default, and allows the subsequent loaded definitions to overwrite the previous ones.

Because we cannot modify the definitions in struts-default.xml and struts-plugin.xml, and struts. XML is usually used to place application-related configurations. At the same time, in order to keep the web. the independence of XML, so here we can summarize a best practice:Put the custom static variable definition to be loaded or the default static variable definition to struts. properties as much as possible.This will make your configuration clearer.

3. overwrite the implementation of struts2 or xwork interface and replace the default behavior mechanism 

Both struts2 and xwork are interfaces-oriented frameworks. (After reading this section, you must understand the benefits of interfaces ). For these defined interfaces, we can write our own implementation classes to implement these interfaces, so as to replace the default behavior mechanism of struts.

In the reference of struts2, also pointed out some struts2 interface extension points, see the following link: http://struts.apache.org/2.0.14/docs/plugins.html

Here, I want to propose that the above link only lists some extensible interfaces of struts2. In addition, many interfaces of xwork are also scalable. Therefore, we can also refer to the xwork configuration file to find more extension points, which will be left for readers to study on their own.

In the subsequent sections, we will also explain how to extend these interfaces based on specific instances to replace struts2's default behavior.