Re: Struts API bean and ConfigHelper

[Don Brown]

I started down this path and quickly became confused.  What I intended 
to do was create a AppContext, similar to the ActionConext, but where 
ActionContext provided request and session services, AppContext provided 
servlet level services.  Unfortunately, I quickly discovered there 
aren't any outside servlet mapping information.  ConfigHelper has mostly 
request and session helper functions, which probably would go into 
ActionContext.  ModuleConfig provides methods for the specific module 
however it isn't easily accessible (through a threadlocal for example).

I guess what I'm trying to say was, giving the current environment with 
ModuleConfig and ActionContext, what exactly does everyone see going 
into a Struts API bean?

Don
Craig McClanahan wrote:
Not so much an "anything else" comment, but you might want to take a
look at a similar bean I built in the struts-faces library so that you
could use value binding expressions to access Struts configutation
stuff.  If you check out the "current" pseudo-directory, the source
code is at:
  faces/core-library/src/java/org/apache/struts/faces/util/StrutsContext.java
There are some JSF-specific things here that wouldn't fit the general
case, but it might serve as a starting point.
Craig
On Mon, 28 Mar 2005 15:57:23 -0800, Don Brown <[EMAIL PROTECTED]> wrote:
I'm looking at bug 9088 and my solution would involve saving all
discovered servlet mappings into probably a ServletMappingHelper which
would provide methods that allowed retrieval of mappings and matching of
existing servlet paths to mappings for the purpose of generating a URL.
Anyways, an object such as that needs to made available somehow, which
gets back to the Struts API bean discussion.  If I'm going to address
this bug, I might as well code up the API bean and do it right.  My
thoughts is this would be an object, patterned after
o.a.s.config.ConfigHelper, which would exist once per Struts instance in
the servlet context.  Additionally, it would be available through a
ThreadLocal variable to allow it to be accessed at any point in the
application (this feature is perhaps debatable).
My goals in designing this bean:
1. Capture all application-level configuration information
2. Replace instances where Struts application-level objects are pulled
out of the servlet context
3. Initially, of course, the application-level objects would still be
available in the servlet context, but hopefully, this could be phased
out by 1.5 perhaps.
Anything else?
Don
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]