I would think we should just have the getter and setter in the interface, and leave the actual thread-local part to the implementation. Note that the getter and setter don't tie the impl to the use of thread-locals, so if someone came up with an alternative impl, that would be OK too.
Isn't the point of the ThreadLocal to make the ActionContext statically reachable to a method which might be invoked without having an instance passed to it?
public void pojoActionMethod() { ActionContext ctx = ActionContext.currentInstance();
if (...) { ctx.setForwardConfig(ctx.getMapping().findForward("a")); }
else { ctx.setForwardConfig(ctx.getMapping().findForward("b")); }
}If we add the methods to the interface, then there's still no way to pull yourself up by the bootstraps in a case like this.
As far as the actual impl of thread-local, I would think we could define an abstract base class that does that part. Or does that negate part of the reason for having ActionContext be an interface? (I haven't been following along as closely as I should have been...)
There is the ActionContextBase abstract class, which would be a suitable place to put it, except for the question of whether we want to put it into the Interface as an instance method at all!
Joe
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
