Stripes-Spring is meant to improve upon the existing support that Stripes provides for Spring. Stripes-Spring provides constructor injection and
the ability to configure your action beans in a Spring context. This has been done with care to not violate the spirit of Stripe's simplicity.
NOTE: Stripes-Spring *DOES NOT* require your ActionBeans to be managed by Spring. It provides
the ability to have your ActionBeans managed by Spring. It does not require that they be. Care is taken to provide a simple and appropriate
option for both Stripes managed injection and Spring Managed injection. Please see summary for further explanation.
Right-Click Link and select save as:
After expanding one of the downloaded distributions, place stripes-spring.jar into your
classpath. Be sure you have spring.jar and stripes.jar in your classpath as well.
Stripes-Spring provides Constructor Injection and "Spring Managed" ActionBeans support using
simple annotations. Although "Spring Managed" ActionBean support is a bit against the grain of Stripes
I went ahead and added it because i figured it would be useful for some who prefer to handle their
injection in the Spring context xml. The feature that I was mainly targeting is the ability to inject
on the constructor. This functionality works in concert with the standard Stripes filter based Spring
support. You can use both together.
Stripes-Spring extends the Stripes default NameBasedActionResolver and overrides the makeNewActionBean method.
You will need to configure the SpringActionResolver subclass in the web.xml.
Add the ActionResolver.Class init-param to your web.xml
<init-param>
<param-name>ActionResolver.Class</param-name>
<param-value>com.silvermindsoftware.stripes.action.SpringActionResolver</param-value>
</init-param>
You can see here in the larger context of the web.xml that SpringActionResolver works side by side with the standard
support Stripes provides for Spring.
<filter>
<display-name>Stripes Filter</display-name>
<filter-name>StripesFilter</filter-name>
<filter-class>net.sourceforge.stripes.controller.StripesFilter</filter-class>
<init-param>
<param-name>Interceptor.Classes</param-name>
<param-value>
net.sourceforge.stripes.integration.spring.SpringInterceptor,
net.sourceforge.stripes.controller.BeforeAfterMethodInterceptor
</param-value>
</init-param>
<init-param>
<param-name>ActionResolver.PackageFilters</param-name>
<param-value>com.foo.web.stripes</param-value>
</init-param>
<init-param>
<param-name>ActionResolver.Class</param-name>
<param-value>com.silvermindsoftware.stripes.action.SpringActionResolver</param-value>
</init-param>
</filter>
Using the @SpringManaged annotation on the class level of your ActionBean you can instruct
Stripes to retrieve your ActionBean from Spring. It has an optional parameter of "id" that you can use
if you do not use the convention. You can define your ActionBean and injection in your Spring context
xml file. Don't forget to set your scope to prototype on the bean (i.e. scope="prototype").
The convention that is used to lookup the managed ActionBean is to take the short name of the ActionBean and lower case its first letter.
The convention that is used to lookup the managed ActionBean is to take the short name of the ActionBean and lower case its first letter.
@SpringManaged annotation parameters
Parameter
Optional
Description
id
Y
The id of the bean defined in the spring context
Example Spring context XML file
<?xml version="1.0" encoding="UTF-8" ?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/...">
<bean id="superDuperActionBean" class="com.foo.SuperDuperActionBean" scope="prototype"/>
<bean id="niftyActionBean" class="com.foo.NeatoActionBean" scope="prototype"/>
<beans>
Example @SpringManaged using convention - will load ActionBean instance from bean id of superDuperActionBean
@SpringManaged
public class SuperDuperActionBean {
// body of class
}
Example @SpringManaged using explicit id - will load ActionBean instance from bean id of niftyActionBean
@SpringManaged(id = "niftyActionBean")
public class NeatoActionBean {
// body of class
}
Constructor Injection allows you to specify a constructor as injectable with the @SpringConstructor.
You must then specify each constructor parameter with a SpringParam annotation. Each @SpringParam has a refId
paramter that must be specified. It would be nice if i could use reflection and retrieve the names
of the parameters as a means of convention. But, Java doesn't provide that nicety. Therefore you must specify
the refId for each @SpringParam. The refId will be used to lookup the defined bean from the Spring context. The
found bean will be passed into the constructor at ActionBean instantiation.
@SpringConstructor - is a simple marker annotation. It has not parameters. It's job is to flag the constructor as the one that will be used to inject into. It is not possible to define more than one @SpringConstructor enabled constructor.
@SpringParam - is used on each constructor parameter to define which bean will be injected from the Spring context.
Parameter
Optional
Description
refId
N
The id of the bean defined in the spring context
Example Spring context XML file
<?xml version="1.0" encoding="UTF-8" ?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/...">
<bean id="personManager" class="com.foo.manager.PersonManager"/>
<beans>
Example @SpringConsructor Usage
public class SuperDuperActionBean {
private PersonManager personManager;
@SpringConstructor
public SuperDuperActionBean(
@SpringParam(refId="personManager") PersonManager personManager)
{
this.personManager=personManager;
}
// additional handers and setters/getters ommitted for breavity
}
In the end the difference betwee @SpringManaged and @SpringConstructor is *who* will instantiate the ActionBean instance. With @SpringManaged it will be Spring.
With @SpringConstructor it will be Stripes that will instantiate the ActionBean and lookup the beans to inject on the constructor parameters. Depending on your
requirements/biases both work just fine. The big plus is that it makes your classes more easily testable.