You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by bu...@apache.org on 2005/01/07 23:37:20 UTC

DO NOT REPLY [Bug 5395] - ActionContext class

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=5395>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=5395





------- Additional Comments From Joe@Germuska.com  2005-01-07 23:37 -------
I started working on this last night before I remembered to look for an existing
Bugzilla ticket.  Anyway, my approach was substantially different, but I'd like
some feedback before I get too far, as there's a fair amount of slogging to do.

I think that ActionContext should be an interface extending o.a.c.chain.Context.
 It should have zero dependencies on the Servlet API.

The ActionContextBase class would provide basic implementations of everything
necessary.  It would be created as a wrapper around a base chain Context, and
store its values in that context.  A ServletActionContext subclass could
reimplement the base methods in a way which took advantage of access to the
session and which could also put values in the request or session scopes in a
way which would be backwards compatible with existing tools that expect to find
things there (although I think we should deprecate that practice in favor of
using the ActionContext).

There are a few sketchy bits, like the way that TokenProcessor is dependent on
HttpServletRequest, and how to represent "sessions" in the
Servlet-API-independent layer.  

I'm attaching a ZIP with work-in-progress.  It's definitely subject to change
and all, but better to show it than sit on it.



-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org