Matt is absolutely correct. You should not need with any kind of bean-loading/instantiating code in your MVC application, otherwise you're doing something wrong. You define your beans inside the according spring XML configuration files.
<bean id="pinboardServiceTarget" class="com.lifepin.services.PinboardService">
<property name="pinboardEntryDao" ref="pinboardEntryDAO"/>
</bean>
...
<bean id="pinboardEntryDAO" class="com.lifepin.daos.PinboardEntryDAO">
<property name="sessionFactory" ref="sessionFactory"/>
</bean>
Your PinboardService class (this is just from an application I wrote recently) will have a property IPinboardEntryDAO
like
public class PinboardService implements IPinboardService{
private IPinboardEntryDAO pinboardEntryDao;
...
public void setPinboardEntryDAO(IPinboardEntryDAO dao){
this.pinboardEntryDao = dao;
}
public IPinboardEntryDAO getPinboardEntryDAO(){
...
}
...
}
public class PinboardEntryDAO implements IPinboardEntryDAO{
...
}
Note that inside the the PinboardService
class I'm using the DAO interface, not the implementation itself, while in the configuration I'm then injecting the real implementation PinboardEntryDAO
. This is a very good practice for separating the different layers (presentation, service and data layer).
There's some kind of magic here, but at the end, everything is a deterministic program.
The DelegatingFilterProxy is a Filter as it was explained above, whose goal is "delegating to a Spring-managed bean that implements the Filter interface", that is, it finds a bean ("target bean" or "delegate") in your Spring application context and invokes it. How is it possible? Because this bean implements javax.servlet.Filter, its doFilter method is called.
Which bean is called? the DelegatingFilterProxy "Supports a "targetBeanName" [...], specifying the name of the target bean in the Spring application context."
As you saw in your web.xml that the bean's name is "springSecurityFilterChain".
So, in the context of a web application, a Filter instantiates a bean called "springSecurityFilterChain" in your application context and then delegate to it via the doFilter() method.
Remember, your application context is defined with ALL THE APPLICATION-CONTEXT (XML) files. For instance: applicationContext.xml AND applicationContext-security.xml.
So try to find a bean called "springSecurityFilterChain" in the latter...
...and probably you can't (for instance if you followed a tutorial or if you configured the security using Roo)
Here is the magic: there's a new element for configuring the security, something like
<http auto-config="true" use-expressions="true">
as it is allowed by http://www.springframework.org/schema/security/spring-security-3.0.xsd, will do the trick.
When Spring loads the application context using XML files, if it finds a element, it will try to set up the HTTP security, that is, a filter stack and protected URLs and to register the FilterChainProxy named "springSecurityFilterChain".
Alternatively, you can define the bean in the classic way, that is:
<beans:bean id="springSecurityFilterChain" class="org.springframework.security.web.FilterChainProxy">
But it's less recommended, since you need to do a lot of configuration (all the filters that you're going to use. And there are more than a dozen of them)
Best Answer
Create a parent context by using ContextLoaderListener. The
DispatcherServlet
contexts will automatically become children of that context.Create your shared beans in the parent context and refer to them in beans in the child contexts.
If you are using
<component-scan>
make sure you don't accidentally scan classes into multiple contexts. See my answer here.