> 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]>
