On Wed, 24 Mar 2004, Craig R. McClanahan wrote: > 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).
Doh! I'd forgotten about that. However, if we made config reading pluggable, people could implement any of the above options today, without the need to subclass ActionServlet. -- Martin Cooper > > > > > -- > > 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]
