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 Ted Husted <[EMAIL PROTECTED]> on 11/15/2001 04:00:21 PM Please respond to "Struts Developers List" <[EMAIL PROTECTED]> To: Struts Developers List <[EMAIL PROTECTED]> cc: Subject: Re: Multiple controller servlets The call to an Action is an URL (or URI) like any other, so declarative security is transparent. The Servlet *delegates* the response to one of its Action, but the Action still has full access to the parent Servlet, so you can continue to use whatever services it offers. The Action does not so much replace the Servlet as much as it extends it. The way it extends it is through the ActionMappings (or Struts config), which is at the crux of the problem of multiple ActionServlets. The tag extensions need to use these too, which is why they ended up in ApplicationScope. When there is more than one set of ActionMappings in play, (as you know) it takes a lot of smoke and mirrors to be sure the tag extensions get the right one. Personally, I'm not going to veto a good implement of multiple ActionServlets; I'm just hoping that we also solve the real problems of multiple Struts configurations. Tim W Wilson wrote: > > A few more questions then... > Access control to servlets is well understood. Can access to particular > actions be controlled in similar fashion? > Isn't it possible that extensions to the programming model from Sun that > extends to servlets would be of no use to a struts application? > I just have this feeling that a single controller servlet is going to end > up duplicating certain types of functions because Action completely > replaces Servlet in the struts programming model. Is this wrong? > > Tim W Wilson > Eclipse WSED Architecture & Development > internet: [EMAIL PROTECTED] > (919) 254-0029 (TL 444-0029) > > Ted Husted <[EMAIL PROTECTED]> on 11/15/2001 09:58:00 AM > > Please respond to "Struts Developers List" <[EMAIL PROTECTED]> > > To: Struts Developers List <[EMAIL PROTECTED]> > cc: > Subject: Re: Multiple controller servlets > > > Of course, I fully expect to see responses saying "both". ;-) I guess my > > question is, what is the real problem people need to solve? > > + Team development > + General manageablitity > + Distribution of plug-and-play Struts "application-lets" > > What this amounts to, I think, is that we need the ability to configure > an application into several "packages" or "modules". > > If we continue to eliminate restrictions, so that we can have multiple > > + Struts configurations > + Application Resources > + Action prefixes/suffixes > + ActionServlet services/extensions > > it all falls into place. > > So, a "package" could be setup under its own subdirectory, > with its own Struts config and set of Application Resources, and > incorporated by reference from the (single) ActionServlet config. > > This *may* mean changes to a package's Struts config, if someone else > was > already using a given package name, but if the package is designed > correctly, > that should be it. No code or JSP changes. (The Struts config is really > *so* > cool.) > > I'd also like to be able to drop the whole /do/ and *.do thing, and just > be > able to register the prefix for each package, so the command line would > look > like > > /module1/Action > /module2/Action > > instead of > > /do/module1/Action > /do/module2/Action > > To do this right, would also mean changes to the Struts DTD > (as already discussed), so that there could be multiple > <struts-config> blocks, along with blocks for service > extensions (validator/tile mappings, object factories, et cetera). > > -T. > > [EMAIL PROTECTED] wrote: > > > > ----- Original Message ----- > > From: "Ted Husted" <[EMAIL PROTECTED]> > > To: "Struts Developers List" <[EMAIL PROTECTED]> > > Sent: Wednesday, November 14, 2001 2:18 PM > > Subject: Re: Multiple controller servlets > > > > > A fix for multiple struts-config has come along first, but the need for > > > multiple resource files is just as great. > > > > Multiple resource files can be used today, as long as you use a different > > bundle name for each set of resources. This works well when you have > > multiple components (or modules), each having their own set of resources. > > > > The question then becomes which functionality people consider to be > missing: > > > > a) Loading multiple resource files and handling them all as if they were > > part of the same default resource bundle. > > > > or > > > > b) Loading multiple resource files, each into its own bundle, > > "automagically" - that is, without having to add your own initialization > > code. > > > > > > > -- > > Martin Cooper > > > > > Once both of these features are added, I believe the use-cases I've > seen > > > would be addressed. > > > > > > The downside of multiple servlets is > > > > > > 1) Since servlets are multi-threaded, there is no performance advantage > > > to having more than one. > > > > > > 2) If for any reason the servlets wanted to use the same utility > Action, > > > each would have to load its own copy. > > > > > > 3) Given multiple configs and resources, most applications would > > > otherwise want all their servlets configured the same way, which means > > > the desired configuration in web.xml have to be replicated. > > > > > > Two use-cases of my own are: > > > > > > 1) Multiple prefix/extension mappings. I tend to design my applications > > > around "packages", each of which have their own "directory". If I could > > > register the root of each package as Action mapping, then I wouldn't > > > have to use /do/ or *.do at all. But that's really another > configuration > > > issue, where the servlet can accept multiple masks. > > > > > > 2) Multiple subclassed servlets to handle different services. The only > > > good way to add services to the controller now is to subclass it. One > > > way to avoid inheritance problems would be to have different subclasses > > > available. But, this would really be better solved by Oledg's > > > ServiceFactory. > > > > > > This isn't to say that I'm against multiple ActionServlets, just that > we > > > should be sure they are used to solve the right problems, and not used > > > to mask problems with configuring a single ActionServlet. > > > > > > Offhand, the only thing that occurs to me about the strategy outlined > > > would be the idea of keeping the multiple ActinServlet Configurations > > > together in a Collection stored in the Servlet/ApplicationContext, and > > > then passing around a key to that collection in the request. The > helpers > > > could then use the key to retrieve the configuration from the > > > Collection. > > > > > > -Ted. > > > > > > Tim W Wilson wrote: > > > > > > > > I would like some feedback on the subject of multiple controller > > servlets. > > > > I have seen some of the previous discussion in the archives. The > basic > > > > problem has to do with modularity - both in the runtime and at > > development > > > > time. The current solution of multiple config files certainly solves > > the > > > > many of the development issues esp. that of managing a single large > > config > > > > file, but what about other resources (messages). When I first > started > > > > using struts my first impulse to deal with modularity was to have > > multiple > > > > controllers and I was quite surprised that I could not do this. The > > idea > > > > of multiple controllers each self contained seemed quite natural. I > > have > > > > since developed a patch that works quite well. But before a submit > it I > > > > would like to know: > > > > Does anyone think this is a bad idea or that the current solution is > > > > complete enough? > > > > Is there a problem with the basic design as detailed below: > > > > > > > > The basic problem in the current code is that the ActionServlet > stores > > some > > > > attributes in the ServletContext; other servlets overwrite these > attrs. > > > > The solution is to have one ActionServletContext per deployed action > > > > servlet. This context is stored in the ServletContext under a unique > > key > > > > for each controller. Those attrs that were stored in ServletContext > are > > > > stored instead in this "local" context. > > > > > > > > A particular context becomes "active" at request handling time. The > > first > > > > thing the action servlet does is to put its local context into the > > request > > > > object using a statically defined key (Action.CURRENT_CONTEXT_KEY). > > Thus > > > > the other part of this patch is updating the access to the > application > > > > scope attributes. These mostly reside in the taglibs (though I bet > > someone > > > > accesses them in their Action class impls). The patch was to create > > helper > > > > methods in RequestUtils that returned these atttrs directly (ex. > > > > RequestUtils.getActionForwards()). These helper methods then access > the > > > > attrs out of the local context in the request using the original keys > > (ex. > > > > Action.ACTION_FORWARDS). > > > > > > > > Now clearly there are times when the active context in the request is > > not > > > > appropriate: > > > > - Welcome pages that were not served by a controller, hence there is > no > > > > active context stored in the request. > > > > - Forwarding to jsps that are not part of the "module" - like back to > a > > > > welcome page. > > > > > > > > I handled the first problem by having a "primary=true" initparm for a > > > > particular action servlet. What this means is that the local context > > attrs > > > > for this servlet are dumped into the global ServletContext at init () > > time. > > > > The RequestUtil helper methods understand to look in the global > context > > if > > > > no local context is found. This would also be done for message > lookup > > (no > > > > msg in locally defined resources, look in global resources). > > > > > > > > The solution to the second problem seems to require programmer > > intervention > > > > (not good): either he explicitly clears the local context out of the > > > > request before forwarding to an "external" resource or uses a special > > > > forward class that knows to do so. However, it can be argued that > the > > > > welcome page is the only page that one should even consider > forwarding > > to > > > > outside the context of a controller servlet; access to other jsps > > should > > > > go through actions the have been configured with the "forward" > > attribute. > > > > This way each "module" has complete control to all its resources. > > > > > > > > Since I am new to Struts I am no doubt missing things here. Thankyou > > for > > > > any comments. > > > > > > > > Tim W Wilson > > > > Eclipse WSED Architecture & Development > > > > internet: [EMAIL PROTECTED] > > > > (919) 254-0029 (TL 444-0029) > > > > > > > > -- > > > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > > > -- > > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > > > > -- > > To unsubscribe, e-mail: < > mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: < > mailto:[EMAIL PROTECTED]> > > -- Ted Husted, Husted dot Com, Fairport NY USA. > -- Custom Software ~ Technical Services. > -- Tel +1 716 737-3463 > -- http://www.husted.com/struts/ > > -- > To unsubscribe, e-mail: < mailto:[EMAIL PROTECTED] > > > For additional commands, e-mail: < mailto:[EMAIL PROTECTED] > > > > -- > To unsubscribe, e-mail: < mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: < mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED] > For additional commands, e-mail: <mailto:[EMAIL PROTECTED] > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
