Yes, but concrete mechanisms for (re-)loading configurations could be pluggable, and therefore optional. One can imagine storing struts config files in a central database, and providing a loader that could load / reload them from there. The location of the configuration files doesn't seem to be very important to struts at the end of the day, just that the information is loaded.
-----Original Message----- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 24, 2004 12:52 AM To: Struts Developers List Subject: Re: Splitting struts-config into multiple jar and read them as resource stream Quoting Martin Cooper <[EMAIL PROTECTED]>: > On Tue, 23 Mar 2004, Martin Cooper wrote: > > > On Tue, 23 Mar 2004, Craig R. McClanahan wrote: > > > > > Quoting Ted Husted <[EMAIL PROTECTED]>: > > > > > > > On Tue, 23 Mar 2004 11:53:55 +0100, Filippo Munafò wrote: > > > > > Perfect! What you did in JSF is exatcly what we need: > > > > > > > > > > "the controller servlet automatically recognize > > > > > 'META-INF/struts- config.xml' resources in any JAR files that > > > > > were included in the application." > > > > > > > > > > When in struts? > > > > > > > > > > Can I help? > > > > > > > > I think we do the same sort of thing in Commons Chain, n'est > > > > pas? > > > > > > > > > > This particular functionality was in relationship to automatically > finding and > > > loading struts-config.xml files (contributed by JAR files dropped > > > in to > the > > > WAR) without having to explicitly note them in context init > > > parameters. > It > > > doesn't really relate to per-request processing. > > > > > > I can't do this today, but anyone who wants to help on this need > > > only > submit an > > > enhancement request (with a patch) to ActionServlet.init() to scan > > > the configuration resources in addition to what it already does. > > > The secret > sauce > > > is to use ClassLoader.findResources() to get the list of URLs to > > > be > processed. > > > > Before anyone does dash off and write this, I'd like to have a brief > > discussion about this in relation to multi-module applications, and > > removing any need to modify web.xml when adding or removing modules. > > This is something I did in a project about a year ago, very > > successfully, so I think it's worth adding to the Struts core. > > So the earlier suggestion / idea was to automatically scan for a > Struts config file in a jar's META-INF. This is a nice idea, but by > itself, it doesn't work in a multi-module application. The problem is > that each module has its own config file, and that config file does > not include the name of the module (and neither should it, IMHO). > > The approach I have used in the past is to create the following > structure within the web app: > > WEB-INF/ > modules/ > default/ > config/ > struts-config.xml > ... other config files ... > jsp/ > ... > moduleX/ > ... > moduleY/ > ... > ... > > I subclassed ActionServlet so that I could reimplement the config > locating code, but it actually wasn't much work at all. > > The really cool thing about this approach is that adding or removing a > module is as simple as adding or removing files and directories. Not > one file needs to be edited. This is great for those of us who don't > trust installers to do the right thing. ;-) > > > In a similar vein, I'd like to talk about separating out the config > > reading somewhat, to allow for alternative mechanisms. > > The point here is that it should be possible to configure Struts in > any of the following ways: > > * Just what we do today, reading the file names from web.xml. > * Auto-locating the config file from META-INF (for 1-module apps). > * The above-described mechanism for multi-module apps. > * Not using Digester at all, possibly not even using XML files. > > What do people think? The only important con I can think of is that you'd need a Servlet 2.3 or later platform for this to actually work (in order to gain access to ServletContext.getResourcePaths()). Other than that, it's perfectly reasonable (and certainly reasonable for Struts 2.x). > > -- > Martin Cooper Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]