This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

Scoped bean lifecycle management

Jul 14th, 2006, 06:58 AM

I am reading, with interest, about request & session scoped beans.
They seem to promise a better solution to the one that I'm currently employing, but I can't seem to find any way of doing the following.

Provide a BeanPostProcessor style hookpoint that is invoked specifically when a bean is created in a particular scope. This post processor would be supplied, in addition to the bean and it's name, a reference to the scope that the bean was instantiated in.

The reason that I wan't to be able to do this is so that the bean can have further injections, based on information which is relevant to the scope but cannot be described in the context file (The session Id, for example)

Is such a mechanism available, if not, is it one that you would consider adding?

Good name there. Anyways, no, no such functionality exists in the current codebase.

It would not be hard to implement such a scope-aware BPP yourself though. The bean name is supplied to all of the methods in the BPP interface, and as such allows one to get at the underlying bean definition (which contains the scoping information), and from then one an have a number of template methods for parricular scopes.

Cheers
Rick

Comment

Thanks for the reply - my issue is not so much hooking up a BPP but having a reference to the scope in which the bean was instantiated (Session, request etc) so that the bean can be initialized further, based upon the scope.
The current BPP implementations only get the bean and its name.

Bob

As for the 'belugabob' name, that is - as they say - 'A long story'

Comment

The fact that one gets the bean name is key. Given the bean name, one can do a lookup in the container of the associated bean definition. Given the bean definition one can then ascertain the scope of that particular bean. Given the scope of the bean, one can then access the underlying storage mechanism (the HTTP Session for example), and then one can, in your case, access the id of the session and supply it to the bean instances(s) as you see fit.

I'll whip up a demo over the weekend (chock a block busy today), or perhaps Costin will step into the breach

Comment

Find attached just the Java source files and Spring XML configuration files that implements the functionality you are looking for. The relevant classes are named ScopeAwareBeanPostProcessor and WebScopeAwareBeanPostProcessor respectively (some extra - trivial (one line) - web.xml configuration is also required in the case of the WebScopeAwareBeanPostProcessor). (I can send the whole web app if you'd like.)

Spring's web infrastructure does actually bind the HTTP request to the current thread, but unfortunately does not provide a means to actually get at it. As a result I had to implement my own (c.f. RequestAccessor and HttpRequestProvidingListener). Bah All for lack of a simple getter.

Hope that helps, cheers
Rick

Comment

Thanks for taking the time to put the sample code together.
I've had a quick look and it all seems to make sense to me - the thing that I was missing was the whole HttpRequestProvidingListener/RequestAccessor business.

Anyway, I'll incorporate this into a test application later this week - I'm tied up with another task this week (And I'm not currently using Spring V2 in any of my projects, as it's still not quite a stable release)

I will let you know how I get on - If this works out as expected, I can see a good argument for these classes to be added to the core framework.

Comment

Indeed. I just packaged those files that addressed belugabob's issue directly. If you want to get access to the whole shebang you can find the relevant source in the '/samples/showcases/mvc-convention/' directory of the 'spring-with-dependencies.zip' bundle of the Spring distribution. You will have to mangle some package names and suchlike but the meat and bones are all there.

(I'd send the full app, but obsessive compulsive that I am I deleted the original source after zipping up the stuff for belugabob )