Conversation scope/context for Cocoon Forms?

[Bruce Atherton <br...@callenish.com>]

I've been using Cocoon Forms for years, and for the most part have 
really appreciated the functionality they have given me.

There is one issue with them that has driven me to distraction and 
caused me more bugs and lost time than I care to remember: the lack of a 
way to create a conversation scope for injected objects that reflect the 
scope of the javascript continuations within Cocoon Flow scripts.

This was earliest seen with Hibernate Sessions. Best practices were to 
use OpenSessionInViewFilter, which gave the hibernate session a request 
scope. But since you typically pull objects out of the database with one 
HTTP request to display on a web form, and then come back from a 
continuation with an edited version of that object in a new HTTP 
request, you end up with a new Hibernate Session but an object from your 
database from the old one. This leads to unbelievable drama trying to 
get the old object into the new session without stepping on another 
version that may have loaded as well, as well as having to do your own 
code to ensure nothing makes the old version out-of-date with regard to 
the database version.

All the modern dependency injection frameworks have a way around this 
now. Spring uses Flow and Conversation Scopes[1]. Seam uses Conversation 
Context[2]. CDI (as shown by the Weld reference implementation) has a 
Conversation Context as well[3]. Guice has no specific conversation 
scope, but allows you to define your own custom one[4].

My question is whether there has been any work done by anyone to add 
this to Cocoon? As I see it, it would need to deal with these circumstances:

1) On entry to flowscript from the sitemap, inject any dependency marked 
as conversation scoped such as a JPA entity manager and run any 
initialization on it.
2) On saving a continuation, the dependency injected object must also be 
saved. There may be an interface function to do things like temporarily 
close open sockets, and if so there would need to be another method to 
reopen when a continuation resumes.
3) On exit of the top level flowscript function (assuming other 
flowscript functions may have been called from that), run cleanup on the 
dependent object and get rid of references to it.
4) On timeout of the continuation, run cleanup on the dependent object 
and get rid of references to it.

Has anyone already done anything like this? I am still using Cocoon 
2.1.11 but this concept is so critical to me I'd bite the bullet and do 
the work of porting to 2.2 if that was the way to get it.

Thanks for any response on this.

[1] 
http://blog.springsource.com/2007/05/08/spring-web-flow-bean-scopes-and-jsf/
[2] 
http://docs.jboss.org/seam/2.2.0.GA/reference/en-US/html/concepts.html#d0e3620
[3] 
http://docs.jboss.org/weld/reference/1.0.1-Final/en-US/html/scopescontexts.html#d0e1839
[4] 
http://code.google.com/docreader/#p=google-guice&s=google-guice&t=CustomScopes