Because it's used in not just the Invocation, but the Interceptors, the Action, the Validators, etc... Having to pass it everywhere would make the whole API have to have it for every call.
> -----Original Message----- > From: Jens Riboe [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 07, 2004 7:00 PM > To: [EMAIL PROTECTED] > Subject: RE: [OS-webwork] Xwork/WebWork2 under extreme load > > > Here's a followup to my previous post. > > Looking at com.opensymphony.xwork.DefaultActionProxy > public String execute() throws Exception { > ActionContext oldContext = ActionContext.getContext(); > ActionContext.setContext(invocation.getInvocationContext()); > String retCode = null; > try { > retCode = invocation.invoke(); > } finally { > ActionContext.setContext(oldContext); > } > return retCode; > } > > Why not just pass the actionCtx into invoke (change of signature) > retCode = invocation.invoke(actionCtx); > instead of relying on thread-based singleton data (thread > local storage) > > Am I missing something? > > Regards / jens > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Behalf Of Jens Riboe > Sent: Wednesday, January 07, 2004 11:56 PM > To: [EMAIL PROTECTED] > Subject: RE: [OS-webwork] Xwork/WebWork2 under extreme load > > > Thanks, > I found it in com.opensymphony.xwork.ActionContext > static ThreadLocal actionContext = new ActionContextThreadLocal(); > ... > public static void setContext(ActionContext aContext) { > actionContext.set(aContext); > } > public static ActionContext getContext() { > ActionContext context = (ActionContext) actionContext.get(); > return context; > } > ... > > 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. > > Kind regards / jens > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Behalf Of Jason Carreira > Sent: Wednesday, January 07, 2004 9:40 PM > To: [EMAIL PROTECTED] > Subject: RE: [OS-webwork] Xwork/WebWork2 under extreme load > > > Yes, The ActionContext is stored in a ThreadLocal > > ActionContext.getContext() gets the instance associated with > this thread. > > ServletActionContext.getRequest() is just a utility helper method for > (HttpServletRequest)ActionContext.getContext().get(HTTP_REQUEST) > > Jason > > > -----Original Message----- > > From: Jens Riboe [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, January 07, 2004 3:40 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [OS-webwork] Xwork/WebWork2 under extreme load > > > > > > I'm complete new to webwork(2) and is browsing the code of > > WW2 and XWork to get some kind of understanding of what is > > going on under the hood. > > > > Something I don't understand is the usage of static methods > > for accessing request information. > > > > The follwing snippet comes from > > com.opensymphony.webwork.interceptor.ServletConfigInterceptor > > protected void before(ActionInvocation invocation) throws > > Exception { > > Action action = invocation.getAction(); > > if (action instanceof ServletRequestAware) { > > HttpServletRequest request = > > (HttpServletRequest)ActionContext.getContext().get(HTTP_REQUEST); > > ((ServletRequestAware) action).setServletRequest(request); > > } > > ... > > > > And this snippet from > > com.opensymphony.webwork.interceptor.TokenInterceptor > > public String intercept(ActionInvocation invocation) > > throws Exception { > > HttpServletRequest request = ServletActionContext.getRequest(); > > synchronized (request.getSession()) { > > if (!TokenHelper.validToken(request)) { return > > handleInvalidToken(invocation); } > > return handleValidToken(invocation); > > } > > } > > > > Both are getting the HttpServletRequest object from a static method. > > > > I haven't traced it further, but is the context data located > > in thread local storage? Else, I don't understand how it is > > supposed to work. > > > > > How is the valuestack handled? Is there one for each incoming > > > request/thread? I'll post some stack traces from JProfiler > > indicating > > > thread deadlock tomorrow. > > Is the deadlock above and the static context data related > in any way? > > > > Any light on this would help. > > > > Kind regards / jens > > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] > > Behalf Of Jason Carreira > > Sent: Wednesday, January 07, 2004 9:12 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [OS-webwork] Xwork/WebWork2 under extreme load > > > > > > Yes, the ValueStack is created for each request and put into > > the ActionContext > > > > > -----Original Message----- > > > From: Mathias Bogaert [mailto:[EMAIL PROTECTED] > > > Sent: Wednesday, January 07, 2004 3:14 PM > > > To: [EMAIL PROTECTED] > > > Subject: Re: [OS-webwork] Xwork/WebWork2 under extreme load > > > > > > > > > All from CVS, as usual ;-) > > > > > > How is the valuestack handled? Is there one for each incoming > > > request/thread? I'll post some stack traces from JProfiler > > indicating > > > thread deadlock tomorrow. > > > > > > Mathias > > > > > > ----- Original Message ----- > > > From: "Patrick Lightbody" <[EMAIL PROTECTED]> > > > To: <[EMAIL PROTECTED]> > > > Sent: Wednesday, January 07, 2004 9:03 PM > > > Subject: RE: [OS-webwork] Xwork/WebWork2 under extreme load > > > > > > > > > > Mathias, > > > > I haven't seen anything like this. Are you using the latest > > > from CVS > > > > (or at least beta 2)? I did a lot of stress testing while doing > > > > performance tuning for WW and I didn't hit anything like this. > > > > However, that doesn't mean it isn't a problem. > > > > > > > > -Pat > > > > > > > > -----Original Message----- > > > > From: [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED] > > > On Behalf Of > > > > BOGAERT Mathias > > > > Sent: Wednesday, January 07, 2004 9:44 AM > > > > To: [EMAIL PROTECTED] > > > > Subject: [OS-webwork] Xwork/WebWork2 under extreme load > > > > > > > > Hi, > > > > > > > > I'm currently stress testing my application on WebLogic > 8.1 under > > > > extreme load. It seems Xwork has some blocking issues, > > > especially in > > > > regard to OGNL > > > > (getting/setting values on the stack). > > > > > > > > Before I go further to investigate deeply, did anyone see > > > this before? > > > > And are there any best practices concerning threads and the > > > way a web > > > > application should be written? > > > > > > > > Thanks, > > > > Mathias Bogaert > > > > > > > > > > > > ------------------------------------------------------- > > > > 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 > > > > > > > > > > > > ------------------------------------------------------- > > > > 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 > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > 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 > > > > > > > > > ------------------------------------------------------- > > 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 > > > > > > > > > > ------------------------------------------------------- > > 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 > > > > > ------------------------------------------------------- > 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 > > > > ------------------------------------------------------- > 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 > > > > ------------------------------------------------------- > 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 > ------------------------------------------------------- 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
