RE: [OS-webwork] Followup to the IRC meeting: ThreadLocal impl

2003-02-07 Thread Jason Carreira
 -Original Message-
 From: Rickard Öberg [mailto:[EMAIL PROTECTED]] 
 
 The context is set by the dispatcher:
 * Set context
 * Create action
 * Invoke action (which may invoke other actions)

I've checked this into the sandbox. It doesn't work exactly like this as I've checked 
it in. Instead, the ActionContext is created and set during the init() of the 
ActionInvocation. This allows the Dispatcher to be VERY simple. All it needs to do is 
create a new ActionInvocation with the Action name and (optional) namespace, and then 
invoke() it. 

Patrick checked in some mods last night to what I did to make action chaining work by 
saving out and passing on the ValueStack to the next ActionInvocation (and 
corresponding ActionContext).

Check out the sandbox and feel free to comment.

Jason


---
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



[OS-webwork] Followup to the IRC meeting: ThreadLocal impl

2003-02-05 Thread Jason Carreira
Ok, so this is a follow-up to the ThreadLocal discussion this morning. 

So during the ActionInvocation.invoke call, if there are no more
Interceptors, it should set the ActionContext into the ThreadLocal?
That's what I was thinking.

The problem is during the ActionInvocation stack. How do the
Interceptors interact with the parameters, the session, and the
application map? I was creating a new ActionContext object and passing
that as part of the ActionInvocation (replacing the Map context in there
now), but the problem is that the getters and setters for Session, etc
are static, so getting the Session and setting something into it doesn't
work if the current instance is not set into the ThreadLocal. On the
other hand, if those setters are made non-static, then in the Action,
you'll have to do:

ActionContext.getContext().getSession() instead of
ActionContext.getSession().

This is the path I started down when I decided I would open it up to the
floor and schedule the meeting.

Any thoughts? 

Jason

--
Jason Carreira
Technical Architect, Notiva Corp.
phone:  585.240.2793
  fax:  585.272.8118
email:  [EMAIL PROTECTED]
---
Notiva - optimizing trade relationships (tm)
 


---
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



Re: [OS-webwork] Followup to the IRC meeting: ThreadLocal impl

2003-02-05 Thread Rickard Öberg
Jason Carreira wrote:

Ok, so this is a follow-up to the ThreadLocal discussion this morning. 

So during the ActionInvocation.invoke call, if there are no more
Interceptors, it should set the ActionContext into the ThreadLocal?
That's what I was thinking.

The context is set by the dispatcher:
* Set context
* Create action
* Invoke action (which may invoke other actions)


The problem is during the ActionInvocation stack. How do the
Interceptors interact with the parameters, the session, and the
application map? 

See above. No problemo.


I was creating a new ActionContext object and passing
that as part of the ActionInvocation (replacing the Map context in there
now), 

IMO the context should not be a part of the request. The 
ActionInvocation corresponds to the ServletRequest (in servlet lingo), 
and the context corresponds to the ServletContext (in servlet lingo).

but the problem is that the getters and setters for Session, etc
are static, so getting the Session and setting something into it doesn't
work if the current instance is not set into the ThreadLocal. On the
other hand, if those setters are made non-static, then in the Action,
you'll have to do:

ActionContext.getContext().getSession() instead of
ActionContext.getSession().


See above. ActionContext.getSession() should be fine.


This is the path I started down when I decided I would open it up to the
floor and schedule the meeting.

Any thoughts? 

As above. Don't try to mix everything together into pure request stuff. 
The ActionInvocation is one thing, the context is different. There are 
*some* stuff that is in between, but not much.

/Rickard

--
Rickard Öberg
[EMAIL PROTECTED]
Senselogic

Got blog? I do. http://dreambean.com



---
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