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>