> -----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 > > > > > > > nicolas De Loof a écrit : > > > >> This means that included module jar must be built with knowledge of > >> the module on witch it will be associated. Not a big issue, as > >> loading from jars should be great for big apps. > >> > >> Nico. > >> > >> Filippo Munafò a écrit : > >> > >>> Yes, the patch has trasparently extended also non default module > >>> config. > >>> > >>> ActionServlet.init() (unmodified) call initModuleConfig first for > >>> default module > >>> and then for each module config found in controller init parameters. > >>> > >>> So you can do something like this: > >>> > >>> <init-param> > >>> <param-name>config</param-name> > >>> > >>> > <param-value>/WEB-INF/struts-config.xml,META-INF/struts-config.xml > </param-value> > >>> > >>> </init-param> > >>> <init-param> > >>> <param-name>config/module1</param-name> > >>> > >>> > <param-value>/WEB-INF/module1/struts-config.xml,META-INF/module1/s > truts-config.xml</param-value> > >>> > >>> </init-param> > >>> > >>> Or, for example, you can put module1 struts-config only in jar and > >>> the default only in WEB-INF: > >>> > >>> <init-param> > >>> <param-name>config</param-name> > >>> <param-value>/WEB-INF/struts-config.xml</param-value> > >>> </init-param> > >>> <init-param> > >>> <param-name>config/module1</param-name> > >>> <param-value>META-INF/module1/struts-config.xml</param-value> > >>> </init-param> > >>> > >>> > >>> Filippo > >>> > >>> -----Original Message----- > >>> From: nicolas De Loof [mailto:[EMAIL PROTECTED] Sent: > >>> Wednesday, March 31, 2004 10:27 > >>> To: Struts Developers List > >>> Subject: Re: Splitting struts-config into multiple jar and read them > >>> as reso urce stream > >>> > >>> As far as I understand your patch, config included in jars is added > >>> to default module config. > >>> Is they're any way to associate a jar (including config) to a struts > >>> module ? > >>> > >>> Nico. > >>> > >>> Filippo Munafò a écrit : > >>> > >>> > >>> > >>>> Following your suggestion, I've just submitted a patch as > >>>> bugzilla Enhancement (#28051). > >>>> > >>>> I've tried to make as few changes as possible to the source of > >>>> action servlet in order to avoid any regression. > >>>> > >>>> Is it ok? > >>>> > >>>> Filippo > >>>> > >>>> -----Original Message----- > >>>> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] Sent: > >>>> Tuesday, March 23, 2004 18:38 > >>>> To: Struts Developers List > >>>> Subject: Re: Splitting struts-config into multiple jar and read > >>>> them as resource stream > >>>> > >>>> 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. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>> -Ted. > >>>>> > >>>>> > >>>> > >>>> > >>>> 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] > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >>> > >>> --------------------------------------------------------------------- > >>> 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] > >>> > >>> > >>> > >> > > > > --------------------------------------------------------------------- > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
