There are two potentially better places to locate JCR functionality. One place might be in the WikiSession, ideally as a property of the WikiSession (e.g., getRepositoryManager()/ setRepositoryManager()). This is a pretty good place, actually, because WikiSession has privileged access to the JAAS Subject that contains the user's Principal set, and the user's private credentials (which we haven't exploited yet).
WikiSession does not work, because WikiSessions are shared across threads (they're stashed in the HttpSession), and therefore it is illegal to put Sessions in there. WikiSessions also live too long.
The other place would be the ActionBeanContext, which Stripes or WikiActionBeanFactory associates with every WikiActionBean/ WikiContext. Our implementation is tentatively called the WikiActionBeanContext (not suprisingly), and right now it doesn't do much more than the standard ActionBeanContext than contain a reference to the WikiEngine and WikiSession. We could certainly add JCR functions to that, as well.
I am not sure about that, since that would mean that any and all backend methods suddenly need to become Stripes-aware, and that is simply just leaking too much information across boundaries. It will also make life of the embedders annoying, when they just want to render content, and they need to carry the entire ActionBean legacy from Stripes into their code - when they really don't even need it.
The JCR Session object is purely and only related to the Model tier, so mixing View or Controller stuff to it sounds icky.
Remember that most of the "events" a user invokes that cause interesting things to happen will be done through event handler methods. Event handler methods are where the JSP scriptlet code will move to, and they will do most of the heavy lifting for business logic.
ONLY when we are talking about a http context. Embedders, or say, even RSS generation internally, would not have it (and would need the DummyHttpRequest & others).
WikiPages == Node sounds good. We'll need to have a bit more discussion on the degree of auto-commit you foresee. I'm thinking in particular of the side-effects this might have if used in combination with the WikiPageTypeConverter (for 3.0), which will wire up and automatically set the correct WikiPage for a WikiActionBean based on the "page" parameter set in the request.
I'm not seeing any autocommit there. All changes need a separate commit() [or in JCR lingo, save()].
But beyond that, WikiPage.setContent()/getContent() sound like good places for persistence logic. PageManager might be good too. I tend to prefer data objects that are fairly stupid, and Manager classes that are smart.
Me too, usually - it's just that in this case, once the WikiPage contains a reference to the Node, we've pretty much lost the game :-)
WikiEngine should go on a diet. I'd like to see something really simple in 3.0. WikiEngine should just contains references to the major Manager classes, and eliminates convenience methods like saveText() and pageExists(), chiefly because they don't contain have method signatures with the right parameters. Certainly, if JCR needs "session awareness" we'll need to do a different API anyhow, so ditching the existing WikiEngine methods would be good.
Did you take a look at the current WikiEngine in the API proposal? It's *very* lean. Too lean, in fact...
But the point is really that we can create a special, self-contained API JAR, which we can say "this is now the public API which won't be changed". This means that even the WikiEngine interface cannot expose too much internals. (You can always then get a WikiEngineImpl for hacking.)
PS. One more thought on WikiSession. The WikiSession's Subject would be a good place to stash the JCR credentials (username and password). I'm thinking, in particular, of Subject.setPublicCredentials() and Subject.setPrivateCredentials.
Mmm... Well, JCR credentials != JSPWiki credentials. We will need to put in the credentials in the property file anyway (in order to allow the engine itself access to the repository outside a Http request, e.g. indexing or whatever). I don't think that the JCR auth system is very good for us anyway, since it's too restrictive. I wasn't planning on using it.
It might make sense to write a "JCR Monitor" similar to SessionMonitor, but for JCR sessions... perhaps something that "autosaves" or "autoflushes" every few minutes? This might be a good place to use JMX TimerMBean, too. (Actually, I'd kind of like to refactor the WikiBackgroundThread to be TimerMBeans, because the existing implementation doesn't always terminate cleanly... but that is another discussion...)
Well, if we keep a JCR Session open through only a single HTTP Request (remember, they're cheap to create, and this seems to be the recommended way at least from the Jackrabbit people), there is no need.
/Janne
