You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Oleg V Alexeev <go...@penza.net> on 2001/11/16 11:13:34 UTC
Re[2]: Multiple controller servlets
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: <ma...@jakarta.apache.org>
TH> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
Best regards,
Oleg mailto:gonza@penza.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>