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? > > <snip/> > It seems arbitrary to me, and more of a burden than simply having a > public static ThreadLocal which most people would ignore -- but if > others prefer this approach, I wouldn't fight it. >
I was actually thinking of "Log log = LogFactory.getLog();", although I admit there tons more differences than similarities. Just to be clear, I'm not pushing this approach, just discussing it. On the initial idea, where you'd declare the ThreadLocal on the interface - did you mean the accessors would be on the ActionContext interface as well? If so, an implementation may choose a different way to provide a result, ignoring the ThreadLocal declared on the interface, right? I haven't caught up yet on the chain implementation. We have ActionContext as an interface. Is there going to be a way to let the user provide a different instance, or is extending ComposableRequestProcessor the recommended approach? If a factory is created to produce ActionContext instances, the getCurrentContext() method can be placed there, reducing the "arbitrary" vibe. > >The instance would be set by the RequestProcessor at the start of the > >chain after the context is created. > > Yes, no matter where we store the ActionContext, my intent would be > to set this in process() right after contextInstance(...). > > 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]
