Hello Ted, May be it is good. But sometimes developer needs to define different servlets with different config-files....
Friday, November 16, 2001, 12:37:09 PM, you wrote: TH> Nothing prevents the use of multiple servlets in an application now, TH> just multiple ActionServlets, and mainly because the ActionMapping TH> address space is "flat". Again, I'd like to see people continue work on TH> making multiple configuration files available to a single ActionServlet. TH> At the same time, a solid strategy, like the one that you proposed, TH> which exposes the correct set of ActionMappings to each request, is also TH> valid. A link to the ActionMappings is being passed in the request now, TH> and so we are just building on that. I very much like the idea of TH> components looking to the request for what they need, and deprecating TH> application scoep access. Another good reason is that it makes testing TH> and simulations easier, since you could manufacture ActionMappings you TH> wanted to try. TH> So, I would suggest that TH> 1) An ActionServlet be marked as the "primary" or a "helper". The TH> default servlet would be exposed using the original application scope TH> attributes. For backward compatibility, the default could be primary. TH> 2) Links to the ActionServlets be retained in a collection in TH> application scope (like the Actions). This could be created and disposed TH> by the primary servlet. TH> 3) When a request comes through an ActionServlet would pass a reference TH> to its ActionMappings along in the request. TH> 4) A public getMappings() method be added to the the ActionServlet, to TH> return the link to "mappings" that it already maintains. Anyone who TH> wishes to use mutliple ActionServlets could use this method to get the TH> appropriate mappings, and would have to confirm that their Actions do TH> not address the application scope instance directly. TH> 5) All Struts components should then refer to the ActionMappings in the TH> request, and look to the application scope only if the ActionMappings TH> were not found in the request. TH> -- Ted Husted, Husted dot Com, Fairport NY USA. TH> -- Custom Software ~ Technical Services. TH> -- Tel +1 716 737-3463 TH> -- http://www.husted.com/struts/ TH> 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 TH> -- TH> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> TH> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- Best regards, Oleg mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
