Janne, I thought it would make sense to start a new thread about JCR sessions. This is an important topic. Thought I'd help if I could.
-------------8<----------- snip -------------8<----------- To make it simple: The idea was to carry a JCR Session in the WikiContext, and tie the Node to the WikiPage. Unfortunately, our old method (and the new Stripes idea) is to create the WikiPage first, then the WikiContext from it. In JCR, we have to do it vice versa - first the WikiContext (to create the Session) and using that, the WikiPage (an object fetched using the Session). These are obviously incompatible. I've been poking around with all sorts of intermediate solutions (wikicontexts without pages) but I haven't yet figured out anything that would not be a horrendous hack. To me this suggests that the entire lifecycle of WikiContext and WikiPage needs to be completely rethought. Also, resource counting is a problem. Currently we just rely on the garbage collector to get rid of contexts and pages. However, Sessions need to be closed properly, so any thinking about the lifecycle needs to take that into account. -------------8<----------- snip -------------8<----------- Just a thought: any reason why JCR sessions couldn't be incorporated into the WikiSession (e.g., as a property?) Other ideas/musings: In Stripes, we have two objects that we really care about: ActionBeans and ActionBeanContexts. The ActionBeanContext wraps the request, response and other stuff. In 3.0, our WikiActionBeanContext subclasses ActionBeanContext, and implements WikiContext, which means that it *is* a WikiContext. The ActionBean, of course, is the UI/event object that parses parameters and responds to user actions -- and it is usually tied to a specific page. In the Stripes lifecycle, the ActionBeanContext is created first. Then the ActionBean is resolved and populated with parameter values. Part of that population process involves looking up the WikiPage that the ActionBean might be requiring. It's looked up by the WikiPageTypeConverter. The ActionBean's setPage() method is then called, and the WikiPage is passed. Now, here's the nifty part. Because we want to make sure the page in the ActionBean and the Wiki[ActionBean]Context stay synchronized, by convention the ActionBean's setPage() method (invoked by WikiPageTypeConverter, remember!) also sets this property for the WikiContext. Putting this all together, what it means is that Stripes creates the WIkiContext first, the the ActionBean, then sets the WikiPage on both. That **sounds** to me like the sequence you want too. Obvious classes to hack would probably include the WikiPageTypeConverter. Does this help? By the way, the scenario I've describe just covers Stripes-injected WikiContexts. But the "ordinary kind" could be handled too... it would involve some mild hacking of WikiContextFactory. Obviously we have lots of control over what happens in that class.
