Table of Contents |
---|
Description
Info |
---|
Spring is |
...
Note |
---|
This section covers the only supported Spring integration technique. However, there are many other ways to tie in to Spring with WebWork. Please see Other Spring Integration for more info. Note that none of these other methods are currently supported and could change at any time! |
Enabling Spring Integration
Turning on Spring support in WebWork is simply a matter of installing the latest Spring jars in to your classpath and then adding the following entry to webwork.properties:
Code Block |
---|
webwork.objectFactory = spring |
a lightweight container, providing centralized, automated configuration and wiring of your application objects, using a technique called "Dependency Injection" |
The Spring Plugin works by overriding the Struts ObjectFactory to enhance the creation of core framework objects. When an object is to be created, it uses the class
attribute in the Struts configuration to correspond to the id
attribute in the Spring configuration. If not found, the class will try to be created as usual, then be autowired by Spring. In the case of Actions, Spring 2's bean scope feature can be used to scope an Action instance to the session, application, or a custom scope, providing advanced customization above the default per-request scoping.
Note | ||
---|---|---|
| ||
Remember: registering Actions with Spring is not required. The Spring alternative is there if you need it, but the framework will automatically create Actions objects from the action mappings. But, if you want to use Spring to inject your Actions, the option is there. |
Features
- Allow Actions, Interceptors, and Results to be created by Spring
- Struts-created objects can be autowired by Spring after creation
- Provides two interceptors that autowire actions, if not using the Spring ObjectFactory
Usage
To enable Spring integration, simply include struts2-spring-plugin-x-x-x.jar in your application.
If you are using more than one object factory, (for example, by including both the Spring and Plexus plugins in your application,) you will need to set the struts.objectFactory property in struts.properties or in one of several XML files via Constant Configuration:
Code Block | ||
---|---|---|
| ||
struts.objectFactory = spring |
Code Block | ||
---|---|---|
| ||
<struts>
<constant name="struts.objectFactory" value="spring" />
...
</struts>
|
Autowiring
The framework enables "autowiring" by default. (Autowiring means to look for objects defined in Spring with the same name as your object property). To change the wiring mode, modify the spring.autowire
property.
Code Block | ||
---|---|---|
| ||
struts.objectFactory.spring.autoWire = type |
The autowire
property can be set to several options.
name | Auto-wire by matching the name of the bean in Spring with the name of the property in your action. This is the default |
---|---|
type | Auto-wire by looking for a bean registered with Spring of the same type as the property in your action. This requires you to have only one bean of this type registered with Spring |
auto | Spring will attempt to auto-detect the best method for auto-wiring your action |
constructor | Spring will auto-wire the parameters of the bean's constructor |
no | Turn off externally defined autowiring. Annotation-driven injection and injection based on Springs *Aware-interfaces still applies |
By default, the framework will at least try to use Spring to create all its objects. If the object cannot be created by Spring, then the framework will create the object itself.
Enabling Spring integration for other application objects is a two-step process.
- Configure the Spring listener
Code Block | ||||||
---|---|---|---|---|---|---|
|
At this point, all objects will at least try to get created by Spring. If they cannot be created by Spring, then WebWork will create the object itself. Next, you'll need to turn on the Spring listener in web.xml:
Code Block | ||
---|---|---|
xml | xml |
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
|
Sample Spring Configuration
...
- Register your objects via the Spring configuration
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd"> <beans default-autowire="autodetect"> <bean id="personManager" class="com.acme.PersonManager" scope="prototype"/> ... </beans> |
Tip | |||||||
---|---|---|---|---|---|---|---|
| |||||||
Since the Spring integration uses a standard Listener, it can be configured to support configuration files other than
See the Spring documentation for a full description of this parameter. |
Initializing Actions from Spring
Normally, in xwork struts.xml
you specify the class for each action. This means that WebWork will create the action Action. When using the default SpringObjectFactory, the framework will ask Spring to create the Action and wire up dependencies as specified as by the default auto-wire behavior.
Tip |
---|
We strongly recommend that you find declarative ways of letting Spring know what to provide for your actions. This includes making your beans able to be autowired by either naming your dependent properties on your action the same as the bean defined in Spring which should be provided (to allow for name-based autowiring), or using autowire-by-type and only having one of the required type registered with Spring. It also can include using JDK5 annotations to declare transactional and security requirements rather than having to explicitly set up proxies in your Spring configuration. If you can find ways to let Spring know what it needs to do for your action without needing any explicit configuration in the Spring |
However, sometimes you might want the bean to be completely managed by Spring. This is useful, for example, if you wish to apply more complex AOP or Spring-enabled technologies, such as Acegi, to your beans. To do this, all you have to do is remove the class attribute from your WebWork action in xworkconfigure the bean in your Spring applicationContext.xml
and then add a bean in applicationContext.xml. The only thing to change the class attribute from your Action in the struts.xml
to use the bean name defined in Spring instead of the class name.
Your struts.xml
file would then have the Action class attributes changed. remember when doing this is that there is a special naming convention when looking up actions in Spring. The convention is action:(optional-namespace/)actionName. For example, if you have an action in no namespace ("") called foo and another action in the /secure namespace called bar, your applicationContext.xml would look like so:
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE beansstruts PUBLIC "-//SPRINGApache Software Foundation//DTD BEANStruts Configuration 2.0//EN" "http://wwwstruts.springframeworkapache.org/dtddtds/springstruts-beans2.0.dtd"> <beans default-autowire="autodetect"> <struts> <include file="struts-default.xml"/> <bean<package idname="action:foodefault" classextends="com.acme.Foo"/struts-default"> <bean<action idname="action:/secure/barfoo" class="com.acme.Foo"/> </beans> |
Your xwork.xml file would then have the action class attributes removed, leaving it like this:
Code Block | ||
---|---|---|
xml | xml | <!DOCTYPE xwork PUBLIC "-//OpenSymphony Group//XWork 1.0//EN" "http://www.opensymphony.com/xwork/xwork-1.1.dtd"> <xwork> <include file="webwork-default.xml"/> <result>foo.ftl</result> </action> </package> <package name="defaultsecure" namespace="/secure" extends="webwork-default"> <action name="bar" class="foobar"> <result>foo<result>bar.ftl</result> </action> </package> </struts> |
Where you have a Spring bean defined in your applicationContext.xml
named "bar". Note that the com.acme.Foo
Action did not need to be changed, because it can be autowired.
A typical spring configuration for bar could look as following.
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE beans <packagePUBLIC name="secure" namespace="/secure" extends="default"> <action name="bar">"-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd"> <beans default-autowire="autodetect"> <bean id="bar" class="com.my.BarClass" singleton="false"/> ... </beans> |
To use session-scoped components with Spring and Struts, see the Spring Session Components Workarounds analysis.
Class Reloading
The Spring plugin can be configured to automatically reload classes that change in the file system. This feature will enable code changes to be "hot deployed" without having to restart the web container. To enable this feature follow these steps:
- Set "struts.devMode" to "true"
- Set "struts.class.reloading.watchList" to a comma separated list of directories, or jar files (absolute or relative paths)
Add this to web.xml:
Code Block type xml <context-param> <param-name>contextClass</param-name>
...
<param-value>org.apache.struts2.spring.ClassReloadingXMLWebApplicationContext</param-value> </context-param>
Add Apache Commons JCI FAM to the classpath. If you are using maven, add this to pom.xml
Code Block type xml <dependency>
...
<groupId>org.apache.commons</groupId> <artifactId>commons-jci-fam</artifactId>
...
<version>1.0</version> </dependency>
Letting the reloading class loader handle all the classes can lead to ClassCastException(s) because instances of the same classes loaded by different class loaders can not be assigned to each other. To prevent this problem we suggest that struts.class.reloading.acceptClasses
is used to limit the classes loaded by the reloading class loader, so only actions are handled by it. This constant supports a comma separated list of regular expressions:
Code Block | ||
---|---|---|
| ||
<constant name="struts.class.reloading.acceptClasses" value="com\.myproject\.example\.actions\..*" />
|
Warning |
---|
This feature is experimental, and should never be used in production systems. |
Settings
The following settings can be customized. See the developer guide.
Setting | Description | Default | Possible Values |
---|---|---|---|
| The autowire strategy |
|
|
| Whether the autowire strategy should always be used, or if the framework should try to guess the best strategy based on the situation |
|
|
| Whether to have Spring use its class cache or not |
|
|
| List of jar files or directories to watch for changes |
| Comma separated list of absolute or relative paths to jars or directories |
| List of regular expressions of accepted class names |
| Comma separated list of regular expressions of classes that will be loaded by the reloading class loader(we suggest to add regular expressions so only action classes are handled by the reloading class loader) |
| Reload the runtime configuration (action mappings, results etc) when a change is detected in one of the watched directories |
|
|
DEPRECATED: struts.objectFactory.spring.enableAopSupport | Uses different logic to construct beans to allow support AOP, it uses an old approach to create a bean, switch this flag if you have problems with Spring beans and AOP |
|
|
Installation
This plugin can be installed by copying the plugin jar into your application's /WEB-INF/lib
directory. No other files need to be copied or createdRemember: this is not required. This is only needed if you wish to override the default behavior when the action is created in WebWork by decorating it with Spring-enabled interceptors and IoC. Keep in mind that WebWork's Spring integration will do standard IoC, using whatever auto-wiring you specify, even if you don't explicitely map each action in Spring. So typically you don't need to do this, but it is good to know the naming convention if you need to.