...

Spring integration is built into framework. In fact, Spring is the default object factory for SAF 2.

Spring Integration

Spring integration is enabled by default. The default object factory is set in the action.properties files.

action

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 action.properties:

webwork.objectFactory = spring

Autowiring

The framework enables "autowiring" by default. (Autowiring means to look for objects 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 object property), then you'll also need a setting for this in your action.properties:. To change the wiring mode, modify the spring.autowire property.

action

webwork.objectFactory.spring.autoWire = type

Options for this setting are:The autowire property can be set to several options.

At this point, all objects By default, the framework will at least try to get created by Springuse Spring to create all its objects. If they the object cannot be created by Spring, then WebWork the framework will create the object itself. Next, you'll need to turn on the Spring listener in web.xml:.

Enabling Spring integration for other application objects is a two-step process.

• Configure the Spring listener

<listener>
    <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>

• Register your objects via the Spring configuration

See the Spring documentation for a full description of this parameter.

<!-- Context Configuration locations for Spring XML files -->
<context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>/WEB-INF/applicationContext-*.xml,classpath*:applicationContext-*.xml</param-value>
</context-param>

Sample Spring Configuration

At this point, you can add the standard Spring configuration at WEB-INF/applicationContext.xml. An example of this configuration is:

<?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"/>
    ...
</beans>

Switching from Builtin IoC to Spring

Switching is quite easy. Spring setup is done as described above. To complete migration, you will have to

1. transfer your configured components from components.xml to applicationContext.xml appropriately. You can safely delete components.xml afterwards.
2. remove the Component Interceptor from your interceptor stack in action.xml. Although it does not hurt to leave it there, it is simply redundant from now on.

<!-- Context Configuration locations for Spring XML files -->
<context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>/WEB-INF/applicationContext-*.xml,classpath*:applicationContext-*.xml</param-value>
</context-param>

Initializing Actions from Spring

Normally, in xwork action.xml you specify the class for each actionAction. When using the SpringObjectFactory (configured as shown above) WebWork default SpringObjectFactory, the framework will ask Spring to create the action Action and wire up dependencies as specified 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.

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 configure the bean in your Spring applicationContext.xml and then change the class attribute from your WebWork action Action in the xwork action.xml to use the bean name defined in Spring instead of the class name.

Your xwork action.xml file would then have the action Action class attributes changed, leaving it like this:.

<!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="com.acme.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 a Spring bean defined in your applicationContext.xml named "bar". Note that the com.acme.Foo action Action did not need to be changed, because it can be autowired.

A typical spring configuration for bar could look as following.

<?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="bar" class="com.my.BarClass" singleton="false"/>
    ...
</beans>

How the code works

• The id attribute in the

...

• Spring configuration corresponds to the class attribute in the

...

• action configuration.

...

• The singleton attribute is set to false

...

• , meaning that Spring will create a new Action class upon each request

...

• , as SAF would do.

...

...