On Wed, Jan 07, 2004 at 11:56:28PM +0100, Jens Riboe wrote:
> What was the design rationale for putting it in thread local storage?
>
> This works for servlets, but it may cause mysterious bugs in Swing
> applications, every time one uses a worker thread for a time consuming
> UI event.
>
> How about putting state info, like actionCtx, config, etc into
> a single XWork object and then let the impl choose to store it
> appropriately. The ctx can then be created from that object.
>
> For a servlet one can use thread-based singleton, like above
> or put it into the servletCtx, and the actionCtx can be created and stored
> into the request.
>
> For a Swing app, it generally suffice to go for a classloader singleton,
> aka static variable, for both config and actionCtx.
I like the way that PicoContainer has done it:
public interface ObjectReference {
Object get();
void set(Object item);
}
Then there can be a ThreadLocalObjectReference, or a
SingletonObjectReference as needed.
I've needed to change the way that things are stored in Pico, and it was
a 5 line change due to this abstraction.
So you have the ActionContext take an ObjectReference of where to store
itself?
Cheers,
Scott
-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
