|Apache Struts 2 Documentation > Home > Guides > Plugin Developers Guide > Plugins|
Struts 2 plugins contain classes and configuration that extend, replace, or add to existing Struts framework functionality. A plugin can be installed by adding its JAR file to the application's class path, in addition to the JAR files to fulfill whatever dependencies the plugin itself may have. To configure the plugin, the JAR should 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 to:
Many 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.
|Plugins are not loaded in any particular order. Plugins should not have dependencies on each other. A plugin may depend on classes provided by Struts Core, but it should not depend on classes loaded by another plugin.|
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.
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.
To include static resources in your plugins add them under "/static" in your jar. And include them in your page using "/static" as the path, like in the following example:
Extension points allow a plugin to override a key class in the Struts framework with an alternate implementation. For example, a plugin could provide a new class to create Action classes or map requests to Actions.
The following extension points are available in Struts 2:
|com.opensymphony.xwork2.ObjectFactory||struts.objectFactory||singleton||Creates actions, results, and interceptors|
|com.opensymphony.xwork2.ActionProxyFactory||struts.actionProxyFactory||singleton||Creates the ActionProxy|
|com.opensymphony.xwork2.util.ObjectTypeDeterminer||struts.objectTypeDeterminer||singleton||Determines what the key and element class of a Map or Collection should be|
|org.apache.struts2.dispatcher.mapper.ActionMapper||struts.mapper.class||singleton||Determines the ActionMapping from a request and a URI from an ActionMapping|
|org.apache.struts2.dispatcher.multipart.MultiPartRequest||struts.multipart.parser||per request||Parses a multipart request (file upload)|
|org.apache.struts2.views.freemarker.FreemarkerManager||struts.freemarker.manager.classname||singleton||Loads and processes Freemarker templates|
|org.apache.struts2.views.velocity.VelocityManager||struts.velocity.manager.classname||singleton||Loads and processes Velocity templates|
|com.opensymphony.xwork2.validator.ActionValidatorManager||struts.actionValidatorManager||singleton||Main interface for validation managers (regular and annotation based). Handles both the loading of configuration and the actual validation (since 2.1)|
|com.opensymphony.xwork2.util.ValueStackFactory||struts.valueStackFactory||singleton||Creates value stacks (since 2.1)|
|com.opensymphony.xwork2.reflection.ReflectionProvider||struts.reflectionProvider||singleton||Provides reflection services, key place to plug in a custom expression language (since 2.1)|
|com.opensymphony.xwork2.reflection.ReflectionContextFactory||struts.reflectionContextFactory||singleton||Creates reflection context maps used for reflection and expression language operations (since 2.1)|
|com.opensymphony.xwork2.config.PackageProvider||N/A||singleton||All beans registered as PackageProvider implementations will be automatically included in configuration building (since 2.1)|
|com.opensymphony.xwork2.util.PatternMatcher||struts.patternMatcher||singleton||Matches patterns, such as action names, generally used in configuration (since 2.1)|
|org.apache.struts2.views.dispatcher.DefaultStaticContentLoader||struts.staticContentLoader||singleton||Loads static resources (since 2.1)|
Let's look at two similar but different plugins bundled with the core distribution.
SiteMesh is a popular alternative to Tiles. SiteMesh provides a common look-and-feel to an application's pages by automatically wrapping a plain page with common elements like headers and menubars.
The sitemesh-plugin.jar contains several classes, a standard JAR manifest, and a plugin configuration file.
While the SiteMesh Plugin doesn't provide any new results, interceptors, or actions, or even extend any Struts integration points, it does need to know what settings have been enabled in the Struts framework. Therefore, its struts-plugin.xml looks like this:
The two bean elements, with the "static" flag enabled, tell Struts to inject the current settings and framework objects into static property setters on startup. This allows, for example, the FreeMarkerPageFilter class to get an instance of the Struts FreemarkerManager and the current encoding setting.
Tiles is a popular alternative to SiteMesh. Tiles provides a common look-and-feel to an application's pages by breaking the page down into common fragments or "tiles".
The tiles-plugin.jar contains several classes, a standard JAR manifest, and a configuration file.
Since the Tiles Plugin does need to register configuration elements, a result class, it provides a struts-plugin.xml file.
For more about bundled and third-party plugins, visit the Apache Struts Plugin Registry.