I can work on getting patches for multiple Struts configuration files to work.
How should we go about specifying the config files in the web.xml file? Here's a couple of ideas I have: 1.) Perhaps we could have them named config[x] replacing "x" with a number. I.e... <init-param> <param-name>config1</param-name> <param-value>/WEB-INF/struts-config1.xml</param-value> </init-param> <init-param> <param-name>config2</param-name> <param-value>/WEB-INF/struts-config2.xml</param-value> </init-param> 2.) Change the current "config" parameter to support a comma delimited list of config files. I.e... <init-param> <param-name>config</param-name> <param-value>/WEB-INF/struts-config1.xml,/WEB-INF/struts-config2.xml</param-value> </init-param> What if anything should be done about duplicates between files? It appears that the current framework allows duplicates. As far as the DTD goes I agree wholeheartedly. I think we should change the root element to <struts> and change the DOCTYPE to: <!DOCTYPE struts-config PUBLIC "-//Apache Software Foundation//DTD Struts Configuration 1.2//EN" "http://jakarta.apache.org/struts/dtds/struts-config_1_2.dtd"> or we can leave it at 1.1, but let people with existing snapshots know that their DTD is now deprecated. -james [EMAIL PROTECTED] http://www.ejcenter.com/struts/ --- Ted Husted <[EMAIL PROTECTED]> wrote: > I agree with Martin, in that I think the most > important thing is support > for multiple Struts configuration files. > > The other piece to the puzzle is the Service > Manager, since this lets > you extend the ActionServlet without subclassing it, > so that the modules > could also configure their own services. > > These two things together may be able to provide the > solutions most > people need when they ask for multiple > ActionServlets. > > Encouraging multiple ActionServlets too soon could > create a host of > other problems. It may still be needed in some > circumstances, but, > personally, I think multiple configs and pluggable > services is a cleaner > approach, that will lead to applications that are > easier to maintain. > > Ideally, it should also be possible to declare the > validation, services, > and messages from the same configuration file, to > allow everything to be > handled together. It's possible that we need to add > a root element to > the file, so that <struts-config> is only part of > the scheme, and other > configurations, like <form-validation> can be nested > within. > > <struts> > <struts-config> > .. > </struts-config> > <form-validation> > .. > </form-validation> > <services> > .. > </services> > <messages> > .. > </messages> > </struts> > > Of course, we should continue to et these be loaded > as separate files > too, as convenient to the developer. > > > -- Ted Husted, Husted dot Com, Fairport NY USA. > -- Custom Software ~ Technical Services. > -- Tel +1 716 737-3463 > -- http://www.husted.com/struts/ > > > [EMAIL PROTECTED] wrote: > > > > Personally, I am firmly in the second camp > (reading multiple config files). > > My reasoning is as follows. > > > > I am working on a large project that will result > in a common framework, and > > product modules which plug in to that framework. > The common framework, and > > all of the product modules, will use Struts. > Product modules can be > > installed and uninstalled by our customers. > > > > Using some kind of 'include' mechanism solves the > problem of different > > product teams stepping on each others' toes when > editing the Struts > > configuration. However, it makes installation and > uninstallation somewhat > > harder, because those applications will have to > understand the structure of > > the Struts configuration file. > > > > Using multiple configuration files allows me to > have one config file for the > > common framework, and then one more for each > product. Each product team can > > concentrate on its own config file, and the > installer and uninstaller only > > have to worry about which files to add or remove, > and not about what they > > contain or how to modify them. > > > > -- > > Martin Cooper > > > > ----- Original Message ----- > > From: "James Holmes" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Saturday, October 13, 2001 4:29 PM > > Subject: Re: [PROPOSAL] XMLMessageResources > > > > > It seems there has been some discussion in the > past > > > about a new config file DTD that would support > having > > > "multiples" so that individuals could work on a > > > particular section without affecting others. It > seems > > > there is also the camp that would rather just > have the > > > servlet read multiple config files. I am > indifferent > > > (at this point) to which solution i think should > be > > > adopted, but think that Struts could certainly > be more > > > "team development" friendly by choosing one and > then > > > offering it. I have some extra bandwith and > would > > > like to get involved in the "core" struts > development. > > > Craig/Ted/Others, I'd be happy to develop one > or > > > both. I guess I'd like to know what people want > to > > > see developed and what has the highest > likelyhood of > > > being incorporated into Struts and I will > develop it. > > > > > > What about the whole debate on multiple > ActionServlets > > > per WAR? If I were to "solve" this would this > be > > > something that could go into the core? > > > > > > -james > > > [EMAIL PROTECTED] > > > http://www.ejcenter.com/struts/ > > > > > > > > > --- Ted Husted <[EMAIL PROTECTED]> wrote: > > > > Can we join this with the idea of having > multiple > > > > Struts configuration > > > > files, or, on a related front, multiple > workflow > > > > configuration files? > > > > > > > > [EMAIL PROTECTED] wrote: > > > > > > > > > > The Struts 1.1 TODO list contains the > following > > > > item: > > > > > > > > > > "XmlMessageResources. Implementation of > > > > MessageResources and > > > > > MessageResourcesFactory that loads message > keys > > > > and strings from one or more > > > > > XML resources or files." > > > > > > > > > > I have an implementation of this which I > would > > > > like to contribute to Struts. > > > > > The implementation is a drop-in replacement > for > > > > the existing > > > > > PropertyMessageResources. In fact, it is > derived > > > > from it, and so shares the > > > > > same file naming scheme for locale-specific > > > > messages. > > > > > > > > "SCHACHTER,MICHAEL (HP-NewJersey,ex2)" wrote: > > > > > > > > > > Martin, > > > > > > > > > > In the jakarta-commons-sandbox, there's a > folder > > > > > called "resources" containing Struts > > > > MessageResources > > > > > and some other classes that I was working > on, but > > > > had > > > > > to put off for a while. > > > > > > > > > > __________________________________________________ > > > Do You Yahoo!? > > > Make a great connection at Yahoo! Personals. > > > http://personals.yahoo.com __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com