Jason Carreira wrote:
If an action calls code A, which in turn calls code B, and A is not XWork aware but B is, then how are you going to pass context to B? I think this is the reason J2EE uses JNDI (with threadlocals) to implement service access through "java:comp/env": it's always there if you know what to look for. With an explicit approach that's not a guarantee.Actions were originally spec'd to have a method, execute(), with no parameters. That was back when we had ServletAware, etc., and the context information would be made available to the Action before it was executed. When it was decided to get rid of these interfaces, to decouple Webwork from Servlets, it was decided to move to ActionContext, which uses a ThreadLocal to save the execution context for the Action in a way that is easily available, local to the current execution, and doesn't have to be passed as a parameter.
Why is it difficult? Whenever there's a thread disconnect you just get the state, and then re-set it when you want to restart the execution. What exactly is the difficulty?Unfortunately, if you want Action preparation, execution, etc, to be able to be run from multiple threads, ThreadLocals are, at the very least, very difficult to use, and, at the worst, unworkable.
The problem is not "right" or "wrong", the problem is the pro's and con's of the various approaches, and AFAICT the explicit approach has some limitations, whereas the non-explicit approach has no limitations.Is this a huge deal? No, not really. Would it be nice to be able to do this the right way? Yes. But, if it is a requirement that old Actions not have to change their method signature and be able to get the params from the ActionContext ThreadLocal, then this is a limitation that can be documented and worked around.
/Rickard
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
