THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
| Code Block |
|---|
webwork.objectFactory = spring |
If you want to change from the default autowiring mode, which is to auto-wire by name (i.e. to look for beans defined in Spring with the same name as your bean property), then you'll also need a setting for this in your webwork.properties:
| Code Block |
|---|
webwork.objectFactory.spring.autoWire = type |
Options for this setting are:
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 |
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:
...
Normally, in xwork.xml you specify the class for each action. This When using the SpringObjectFactory (configured as shown above), this means that WebWork will ask Spring to create the action and wire up dependencies as specified as by the default auto-wire behavior. The SpringObjectFactory will also apply all bean post processors to do things like proxy your action for transactions, security, etc. which Spring can automatically determine without explicit configuration. For most usages, this should be all you need for configuring your actions to have services and dependencies applied.
| Tip |
|---|
We strongly recommend that you find declarative ways of letting Spring know what to provide for your actions. This includes 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, and using JDK5 annotations to declare transactional and security requirements. 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 applicationContext.xml, then you won't have to maintain this configuration in both places. |
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 configure the bean in your Spring applicationContext.xml and then change the class attribute from your WebWork action in the xwork.xml and then add a bean in applicationContext.xml.
The only thing to 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:
...
to use the bean name defined in Spring instead of the class name.
Your xwork.xml file would then have the action class attributes removedchanged, leaving it like this:
| Code Block | ||||
|---|---|---|---|---|
| ||||
<!DOCTYPE xwork PUBLIC "-//OpenSymphony Group//XWork 1.0//EN" "http://www.opensymphony.com/xwork/xwork-1.1.dtd">
<xwork>
<include file="webwork-default.xml"/>
<package name="default" extends="webwork-default">
<action name="foo" class="foo">
<result>foo.ftl</result>
</action>
</package>
<package name="secure" namespace="/secure" extends="default">
<action name="bar" class="bar">
<result>bar.ftl</result>
</action>
</package>
</xwork>
|
Where you have Spring beans defined in your applicationContext.xml named "foo" and "bar".
Remember: 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 that cannot be automatically determined by Spring. 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 how this can be done if you need to.