Yes, encapsulating the dependencies on a single ActionServlet is a subtle point, but on the list people have said they did it, either by extending their own versions of Struts or adding a parameter to the an extended version of the taglibs.
The RoadMap contemplates doing this in the 1.6.x series, since by then, the dependencies should be obvious. * http://struts.apache.org/milestones.html IMHO, the "there can only be one" mentality is one of the walls we should tear down, but, as Martin says, it hasn't been such a great stumbling block to make it a priority. -Ted. On Apr 12, 2005 9:25 AM, Joe Germuska <[EMAIL PROTECTED]> wrote: > Actually, I think Martin's point might help focus the intention > better; in retrospect, the fact that you can only have one Struts > ActionServlet demonstrates a design shortcoming (even if a pragmatic > one, considering that it hasn't hindered many apps being built upon > Struts.) > > 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] > > -- HTH, Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
