At 06:58 AM 11/15/01, Ted Husted wrote: > > 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".
I agree, and I claim that the way to handle resources in this case is to have each package or module use its own resource bundle. That solves all three of the points you make above. The missing link, then, would be a way of having them be loaded automagically. In my view, this makes more sense than trying to merge multiple resource files into one default bundle at run time. In that situation, there are issues of potential conflicts between the files, amongst other things. >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 is almost exactly the problem I am trying to solve right now in my "day job". I'm in the process of designing a common framework, which includes a base UI, which other product specific components plug into. I need the whole thing to be dynamic, and I want to avoid having an installer which knows how to modify XML files. The subdirectory idea is one of the ideas I'm working through, although in a slightly different form from what you describe. For example, one idea would be to have a directory that contains all the Struts config files for each plugin. I like this much better than the proposed scheme of comma-separated file names in the Struts config file, because now my installer only needs to drop a new config file in the right directory, and it will be picked up and parsed automagically. Even better, my uninstaller only has to delete that file, rather than modify a file that another installer may have modified since its corresponding install. >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.) Right. And I'd like to go one step further, if possible, and find a way to do this without even having to modify the original Struts config file for the overall app. >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). If we modify the DTD, we might also want to think about moving some of the init-param entries into the config file. Since we would be freed from the restrictions of the web.xml DTD at that point, we'd have more flexibility to do things like adding multi-valued parameters. For example, you might be able to specify multiple resource file names as separate value elements for the same parameter name, again getting rid of the need for comma-separated values. >-T. -- Martin Cooper >[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]>
