(Janne -- you should interpret my comments, below, as informational
rather than argumentative. Use, or not, as you see fit.)
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.
Are you sure they are stashed in the HttpSession? The original
implementation I wrote took great care to make sure that they weren't.
That MIGHT have changed due to a bug fix, but I just took a look at
SessionMonitor and WikiSession, and I could not find when WikiSession
was actually stashed. A quick reference-skim for
HttpSession.setAttribute() didn't turn up anything either.
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.
That's a good point. But, the Stripes stuff that is referenced by
WikiContexts/WikiActionBeans is pretty minor, though. And because of
the way I've had to retrofit it into our existing classes, it is done
in a way that is transparent to the rest of JSPWiki. The contract is,
basically, that if a WikiContext is created through any of the four
possible methods (StripesFilter, useActionBean tag,
WikiEngine.createContext() or WikiActionBeanFactory.newActionBean()),
it will be guaranteed to have a non-null WikiActionBeanContext made
available to it (via the required ActionBean method getContext()). The
WikiActionBeanContext itself contains only four references: for
WikiEngine, WikiSession, HttpServletRequest and HttpServletResponse.
That's it -- no other references to Stripes objects, and no long
chains of object references pulling in lots of heavyweight stuff.
(I've written up the approach in the "doc/README - Stripes Migration"
file, in ARJ_STRIPES_BRANCH.)
I'm NOT actually trying to argue that WikiActionBeanContext is the
right place to put the JCR code (or a reference to a class that
contains it) -- just pointing out that it's not as heavyweight as you
might think. It will always be available, which makes it a decent
place to put stuff. And a new one is created, fresh, for every HTTP
request.
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).
You can still execute handler methods outside of Stripes. What you
won't get are the automatic property binding and validation features.
But event methods should still work fine. And more to the point,
handler methods can return any type they want or throw Exceptions.
That makes them useful in non-Stripes contexts.
Also, the WikiActionBeanFactory methods for creating new WikiContexts/
ActionBeans, by necessity, create a backing WikiActionBeanContext
object and mock request/response objects, if not supplied by callers.
This allows for backwards compatibility with
WikiEngine.createContext() -- critical for JSP migration. That is
really all the event handler methods need to function properly.
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...
I am overdue in looking at this... :)
