Page Comparison

...

This would seem to be a good candidate for effectively auto-wiring things like ProfileRequestContexts or HttpServletRequest/Responses.  The processor could either like look for an -Aware interface that we define, or could use full reflection to figure out where/when to wire.

...

This is an interface for a component which post-processes (primarily) BeanDefintionsBeanDefinitions. It can be defined in the context as just another bean, and the context auto-registers it based on its type.  It can have dependencies/collaborators injected into it just like any other bean, which in this case can be used to configure how it works. It has 1 callback method:

...

This technique essentially allows a <bean> definition to inherit various properties of a parent bean.  Basically it's a way to do templating  It templating.  It is implemented by simply declaring  declaring a parent bean reference on the bean:

...

At first I thought this would be of little use to us.  But on more thought, I  I suppose it might be. It might be attractive to wire up our dozens or hundreds of action/handler type beans this way, rather than with reams of XML config.

...

The type of proxy injected my may be either a class-level or interface level proxy.  The former is the default and uses the CGLIB library.  This type of proxy only intercepts public method calls.

...

• Actual Spring autowiring on the whole container could be used, but at the cost of either marking every action with autowire or pretty global container config with default-autowire.  The effect of the latter can be mitigated somewhat with the autowire-default-candidates attribute.
• Bean definition inheritance is the least auto-magical and makes the dependencies more obvious.  But does request require marking all beans with parent.
• BeanPostProcessor could be used to wire based on either an interface (e.g. action instance of ProfileRequestContextAware) or using Java reflection.  Is auto-magical and makes the dependencies less clear, but also results in a very clean config, with no possibilities for errors due to accidental omissions.
• BeanFactoryPostProcessor could be used to actually alter the BeanDefinitions.  Need to prove out that this would actually work.  If does, would have mostly the same advantages and disadvantages as BeanPostProcessor.
• Instead of actually declaring all the action beans in XML, we could possibly consider declaring some or all of them in Java code using the Java-based config technique.  This needs more research.

...