On Apr 11, 2005 1:46 PM, Don Brown <[EMAIL PROTECTED]> wrote: > 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).
Just to throw some more food for thought into the mix... If we allow multiple servlet mappings, someone is going to decide they want to have those mappings reference different <servlet> entries in web.xml, so that they can use a different set of config files for each mapping. That will raise the spectre of multiple instances of ActionServlet again. So I think we need to consider what we're really trying to accomplish by potentially having multiple servlet mappings, multiple servlet instances, multiple modules per servlet, multiple config files per module, etc. -- Martin Cooper > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
