view of ContentManager, but really don't in the filesystem. Case in point: page-save approval workflow tests are failing because, in order to create the WikiContext, we create a page node but it does not get saved until somebody actually approves it.
That's actually a different issue: since you can't guarantee that the next HTTP request is handled by the same Thread, and Sessions are per Thread, we cannot store page-save approval workflows into the Session. They actually need to be flushed to the persistence layer (=saved to the filesystem), or else the workflow won't be there to be approved, unless you're really lucky.
Perhaps this is the reason why things are failing? Also note that once request is over, we flush any unsaved stuff with Session.refresh() (or Session.logout(), don't remember which) to make sure it does not grow uncontrollably.
This is why we need to either store Workflows in-memory or on-disk.
To bring some clarity to this, I'd propose we define a page node as "existing" of it 1) is present in the JCR, and 2) has been saved; i.e., Node.isNew() returns false. I can't think of any reason why this wouldn't work, or any odd side-effects. I suppose it's possible that within a particular thread, multiple page adds could step on each other before the JCR Session save(). But that's about it, and any cases where we see this could be worked around easily.
I think it's fine, but we must remember that any WikiPage.save() causes a new version in the repository.
Anybody want to BTW make sure all our unit tests also run with Jackrabbit?
/Janne
