My two cents about Martin's points: 1 & 2) Having jar's name correspond to a module name.
Interesting, but: - what about mixing subproject's jar and module's jar? How can we mix and discover them? - not common, but how if a jar need more configs, one for a module and one for another? 3) Mixing auto-configuration with explicit configuration. As you said, this idea is not so good for independent teams. Instead, a team with a control over all subprojects could benefit of this feature, as we do now. 4) Factor out the configuration code and make it pluggable. Ok. As Joe said in another post, this is the main point. What do you think about the default config reader? I think it should look inside the war searching for files whose relative paths are the lists of values of the config init parameter (and the default could be "/WEB-INF/struts-config.xml, META-INF/struts-config.xml", plus tiles and validation's one) If my configs (files, db tables, urls, ...) are outside the war, I can write a class that implement an interface (in a way Joe explained very well). So, my question is: are you sure that the enhancement of reading config files through jars is not something missing in the default behaviour? Craig said: > Along the same lines, one of the things we did in JavaServer Faces (with regards > to configuration) is to have the controller servlet automatically recognize > "META-INF/faces-config.xml" resources in any JAR files that were included in > the application. This makes it very easy to package a module, or some other > sub-unit of an overall webapp, as a single JAR file that self-configures. Why it is so in JSF and could not be in Struts? Filippo -----Original Message----- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: Friday, April 02, 2004 08:48 To: Struts Developers List Subject: RE: Splitting struts-config into multiple jar and read them as reso urce stream > -----Original Message----- > From: Craig McClanahan [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 01, 2004 2:00 AM > To: Struts Developers List > Subject: Re: Splitting struts-config into multiple jar and read them as > reso urce stream > > > nicolas De Loof wrote: > > > Just a detail I just think about : > > Using this patch, web can develop a Struts module as a subproject and > > include it in WAR as a jar, but what's about tiles-def.xml and > > validation.xml ? > > > I agree with your thinking ... if we concieve that a module should be > "self configured" simply by having its JAR file included in the webapp, > then we need to cover these bases as well. > > > This plugins should get a similar enhancement to be able to build > > jar-modules with Struts "commonly used" plugins. > > And should be able to adapt to whatever multi-module design > emerges as well. Absolutely. I would much rather think all of this through, rather than rush into an enhancement that seems interesting on the face of it, but that we'd end up wanting to change in the long (or even short) term. Let me throw out a few thoughts on this thread, and modules in general, as I try to catch up. (I'm still in this seemingly-perpetual state of not having the time to fully expound on my thoughts on future enhancements to modules, darn it! ;) 1) The idea of a one-to-one mapping between modules and jars, together with auto-configuration, is an interesting one, and in certain scenarios could work very well. However, if we want to allow for this, I would much rather have the jars not know what their module names are, and have that configured (or auto-determined) through some other mechanism. This is similar to the way that a web app doesn't have to know its context path ahead of time. Taking the web app analogy one step further, one idea might be to take the jar name as the module name, just as a war file name is used as part of the context path. So foo.jar would correspond to a module named 'foo', and default.jar would correspond to the default module (assuming, of course, that these jars have a struts-config.xml file under META-INF). 2) The one-to-one mapping idea is most useful when modules are considered as independent entities (as they are intended to be with the current design), or at least independently configured entities. Once the ideas of shared configuration or inter-module dependencies are introduced, it starts to lose some (but not all) of its appeal. For example, if multiple modules wanted to share some message bundles to avoid loading multiple copies of them, that configuration would have to live somewhere outside of the module jars. As another example, in a hierarchical module scenario, there would need to be a way to specify inter-module dependencies. 3) Mixing auto-configuration with explicit configuration seems like a really bad idea, and a recipe for trouble, to me. Imagine trying to debug an application in which you have some explicitly defined struts-config.xml files as well as some jar files which might, or might not, include their own configuration. This might not be so bad if you know, or have control over, the entire application, but consider the case in which modules are being used to allow multiple independent teams to work on a single web application (which, not incidentally, was one of the major original justifications for introducing modules the way they are today). 4) As I've mentioned before (in this same thread, I think), I believe we need to factor out the configuration code and make it pluggable. Going forward, the Struts Core should rely on certain configuration objects being defined, without caring about how they got there. The default config reader, obviously, would do what we do today, but we should make it easy to provide an alternate config reader that might do its thing in an entirely different manner. (I'm sure the IoC fans out there will have something to say on this topic. ;) Well, that got a *lot* longer than I originally intended. Sorry, folks. Not sure if that's ultimately good or bad... -- Martin Cooper > > Nico. > > Craig > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
