Nothing prevents the use of multiple servlets in an application now, just multiple ActionServlets, and mainly because the ActionMapping address space is "flat". Again, I'd like to see people continue work on making multiple configuration files available to a single ActionServlet.
At the same time, a solid strategy, like the one that you proposed, which exposes the correct set of ActionMappings to each request, is also valid. A link to the ActionMappings is being passed in the request now, and so we are just building on that. I very much like the idea of components looking to the request for what they need, and deprecating application scoep access. Another good reason is that it makes testing and simulations easier, since you could manufacture ActionMappings you wanted to try. So, I would suggest that 1) An ActionServlet be marked as the "primary" or a "helper". The default servlet would be exposed using the original application scope attributes. For backward compatibility, the default could be primary. 2) Links to the ActionServlets be retained in a collection in application scope (like the Actions). This could be created and disposed by the primary servlet. 3) When a request comes through an ActionServlet would pass a reference to its ActionMappings along in the request. 4) A public getMappings() method be added to the the ActionServlet, to return the link to "mappings" that it already maintains. Anyone who wishes to use mutliple ActionServlets could use this method to get the appropriate mappings, and would have to confirm that their Actions do not address the application scope instance directly. 5) All Struts components should then refer to the ActionMappings in the request, and look to the application scope only if the ActionMappings were not found in the request. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel +1 716 737-3463 -- http://www.husted.com/struts/ Tim W Wilson wrote: > > I agree with everything that been said so far, and thank you very much for > this discussion, but let me clarify what I meant by extended services to > servlets not being available. Take something like the "loadOnStartup" init > parm. The web app descriptor has control over what should be loaded or > not. Now with struts the web app has no control over whether to load an > action or not. I understand that an action class will only be loaded on > access but this is not the point. Future extensions to the servlet > programming model think in terms of multiple servlets being in a web app. > Is it not possible for some of these extensions would have something to do > with how servlets interact (formal definition of "module" for all the same > reasons we want them, for instance). This is about the only thing I can > come up with to continue this particular part of the thread. I'm not > really wed to either model as long as one exists in the near future. I am > certainly willing to contribute here. > > -Cheers -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
