As requested by another user; let me share the love for DelegatingFilterProxy
The problem is that you have filters which require collaborators. Those collaborators are managed by Spring. Hmm, what do you do?
Assume:
How do you wire these up? If you are a simpleton like me you would have some code like this:Code:interface Collaborator { boolean canIProceed(); } public final class MyFilter implements Filter { private Collaborator collaborator; //// }
Immediately the code becomes incredibly fragile (looking up by strings) and very difficult to test.Code:public class CollaboratorAwareFilter extends GenericFilterBean { private Collaborator collaborator; protected final void initFilterBean() throws ServletException { super.initFilterBean(); WebApplicationContext wac = WebApplicationContextUtils.getRequiredWebApplicationContext(getServletContext()); collaborator = (Collaborator) wac.getBean("collaborator"); } protected final Collaborator getCollaborator() { return collaborator; } }
(To the fanfare of trumpets) DelegatingFilterProxy comes to our rescue. It basically is a filter which will delegate to a filter retrieved from the current applicationContext.
In other words, I have a filter that looks like:
I have a "filters-context.xml":Code:public class MyFilter implements Filter { private final Collaborator collaborator; public MyFilter(final Collaborator theCollaborator) { this.collaborator = theCollaborator; } ... }
and in web.xml:Code:<bean id="myFilter" class="uk.mycompany.MyFilter"> <constructor-arg index="0" ref="collaborator"/> </bean>
Note: DelegatingFilterProxy will use the value filter-name as the name of the bean. If this does not suit, you can provide the name of the bean via the "targetBeanName" parameter.Code:<filter> <filter-name>myFilter</filter-name> <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class> </filter>
Yeah for Spring
HTH![]()



Reply With Quote
