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.
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...) -- Martin Cooper On Thu, 10 Mar 2005 20:10:30 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote: > So, I was just about to add support for static access to the > "current" ActionContext using ThreadLocal, and then I realized that > this approach is more commonly used with classes than with interfaces. > > Since ActionContext is an interface, we'd have to do something like this: > > public static final ThreadLocal currentInstance = new ThreadLocal(); > > Is it too weird to have this as a public member? Is there some > artful way to hide it more? Of course, we'd have > public static void setCurrentInstance(ActionContext ctx) > and > public ActionContext getCurrentInstance() > > but I'm sketched out at having to leave the member itself public. > > That said, I'm still happier with ActionContext as an interface than > an abstract class. > > Any words of wisdome, or should I just go ahead and do this? > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
