----- 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. Of course, I fully expect to see responses saying "both". ;-) I guess my question is, what is the real problem people need to solve? -- 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]>
