Re: JCR sessions

[Janne Jalkanen <Ja...@ecyrd.com>]

> Just a thought: any reason why JCR sessions couldn't be incorporated
> into the WikiSession (e.g., as a property?)

They're not thread-safe.  However, WikiSessions may be shared across  
multiple threads (e.g. requests could be in different threads).  And,  
to be precise - a JCR Session object is intended to be used by a  
single thread throughout it's entire lifetime.  It's not a question  
of it being used by multiple threads at the same time - it is most  
definitely Thread-bound.  Which is why they are cheap to create.

In addition, we don't want to keep too many JCR Sessions open into  
the repo at the same time, as it increases the chance of conflicts.

So JCR Sessions need to be either ThreadLocal, or 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.

Not really - I'm strictly looking at this from an API point of view.   
I don't want to tie Stripes into JSPWiki any more than what we have to.

I've been trying to hack WikiContextFactory, but so far it my efforts  
seem to turn WikiContextFactory into something which completely  
replicates WikiEngine functionality, which is utterly wrong.  I'm not  
sure whether a publically accessible WikiContextFactory is a good  
idea in the first place since it is ending up doing a whole lot more  
than just creating WikiContexts.  I much prefer the old  
WikiEngine.createContext() facade as opposed to revealing the factory.

/Janne