At 12:11 AM -0500 3/12/05, Paul Speed wrote:
Joe Germuska wrote:
So, I was just about to add support for static access to the
"current" ActionContext using ThreadLocal, and then I realized that
...
...snip...
... member? Is there some artful way to hide it more? Of course, we'd have
public stat
Joe Germuska 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:
p
On Fri, 11 Mar 2005 11:22:54 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote:
> At 10:08 AM -0600 3/11/05, Hubert Rabago wrote:
> >What about using a different class to host the ThreadLocal?
> >
> It seems arbitrary to me, and more of a burden than simply having a
> public static ThreadLocal which
At 10:08 AM -0600 3/11/05, Hubert Rabago wrote:
What about using a different class to host the ThreadLocal?
public void pojoActionMethod() {
ActionContext ctx = ActionContextHolder.getActionContext();
if (...) { ctx.setForwardConfig(ctx.getMapping().findForward("a")); }
else { ctx.setFo
What about using a different class to host the ThreadLocal?
public void pojoActionMethod() {
ActionContext ctx = ActionContextHolder.getActionContext();
if (...) { ctx.setForwardConfig(ctx.getMapping().findForward("a")); }
else { ctx.setForwardConfig(ctx.getMapping().findForward("b"))
At 9:02 PM -0800 3/10/05, Martin Cooper wrote:
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 altern
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 th
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 Th
