incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Jaquith" <andrew.r.jaqu...@gmail.com>
Subject JCR sessions
Date Wed, 31 Dec 2008 18:15:07 GMT
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.

Mime
View raw message