So, by identifying the ways in which Struts depends on a singular ActionServlet, perhaps you could then begin to draw boundaries to encapsulate those concerns into a Struts API bean, so that eventually, each ActionServlet could have its own instance of a Struts API bean and two could coexist peacefully. So even if that means its largely a container of ModuleConfigs and RequestProcessors (so that there can be more than one "default module"), then that's a start right there.
Joe
At 9:31 PM -0700 4/11/05, Martin Cooper wrote:
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.
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
