org.codehaus.groovy.grails.web.plugins.support
Class HandlerMappingInterceptorWiringBeanFactoryPostProcessor

java.lang.Object
  org.codehaus.groovy.grails.web.plugins.support.HandlerMappingInterceptorWiringBeanFactoryPostProcessor

All Implemented Interfaces:

BeanFactoryPostProcessor

public class HandlerMappingInterceptorWiringBeanFactoryPostProcessor
extends Object
implements BeanFactoryPostProcessor

This class automagically wires all HandlerInterceptors and WebRequestInterceptors (web interceptors) in a Spring BeanFactory to all AbstractHandlerMappings.

As to be expected such an implementation cannot handle each and every situation. The goal however is to move this wiring logic out of Grails plugin implementations. To make this abstraction useful for everyone writing plugins we make these assumptions:

• HandlerInterceptors, WebRequestInterceptors and AbstractHandlerMappings are not created by FactoryBeans or factory methods.
• HandlerInterceptors, WebRequestInterceptors and AbstractHandlerMappings are not created by child bean definitions. This requirement is enforced.
• HandlerInterceptors and WebRequestInterceptors should be registered as singletons. This requirement is enforced.
• HandlerInterceptors, WebRequestInterceptors and AbstractHandlerMappings should not be registered with the BeanFactory without bean definition. This requirement cannot be enforced. Notice however that objects registered in this fashion will not be wired at all.
• HandlerInterceptors, WebRequestInterceptors and AbstractHandlerMappings should not be registered as inner bean definitions. It's very unlikely someone would do this. This requirement could be enforced but isn't.
• It may make sense to register a web interceptor explicitly for one or more AbstractHanlderMappings. This wiring implementation however does not support this very well. First of all, all HandlerInterceptors and WebRequestInterceptors will be registered to all AbstractHanlderMappings. And secondly, aliases make it hard or even impossible to have a fail-proof protection against double registration of web interceptors with WebRequestInterceptors. To make things easy we don't accept any injection in the interceptors property at this time.

While these limitations are not expected to block plugin developers they are important to be aware of when registering HandlerInterceptors, WebRequestInterceptors and AbstractHandlerMappings. If you're experiencing difficulties by these restrictions please do send a mail to the developer mailing list.

As a side-note, this is a pessimistic implementation that could be replaced by an optimistic one using object-oriented design to select and refuse web interceptors.

Since:

2 jan 2007

Author:

Steven Devijver

Constructor Summary

HandlerMappingInterceptorWiringBeanFactoryPostProcessor()

Method Summary

void	postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory)

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Constructor Detail

HandlerMappingInterceptorWiringBeanFactoryPostProcessor

public HandlerMappingInterceptorWiringBeanFactoryPostProcessor()

Method Detail

postProcessBeanFactory

public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory)
                            throws BeansException

Specified by:

postProcessBeanFactory in interface BeanFactoryPostProcessor

Throws:

BeansException