Like the title implies, a request for opinions on what I think is a neat trick.
I want to use Spring to manage per-HttpSession objects in my app. For various reasons, I don't want to use the FormController approach (these session objects can't be targets of request binding, for instance.)
i.e., I want my context description to look a little like this (and definitely NO MORE verbose: )
...and doesLotsaStuff should just magically use the correct justamap for the session currently being handled, without being any the wiser. JSPs, etc., could refer to justamap and get the correct object too.
<bean id="justamap" class="java.util.HashMap" singleton="false"/>
<bean id="bindToSession" class="MyHttpSessionAutoProxyCreator">
I have actually made this work! It's pretty slick. However, some of my hacking under the covers makes me nervous:
-- I have to hook into the context startup in lotsa places: my class is a BeanPostProcessor, BeanFactoryPostProcessor, ApplicationListener, BeanNameAware, and has an inner class that's a FactoryBean and TargetSource. Whew.
-- I detect the currently-being-handled request by intercepting calls to the HandlerMapping (request starts) and getting RequestHandledEvents (request ends) and use a ThreadLocal. good/bad?
-- 'justamap' gets forcibly replaced by an AOP proxy, instead of the proxy being fetched from a FactoryBean. Bad form: nobody else can get at the unproxied template anymore. I'd rather use a FactoryBean, but see below.
I ran into what may be a bug: say a FactoryBean also implements BeanPostProcessor. When an ApplicationContext is detecting BeanPostProcessors, it finds the factory itself but tries to use the factory's product as a BeanPostProcessor, which it likely is not. Shouldn't the context both detect and fetch BeanPostProcessors in the same way?