> -----Original Message----- > From: Filippo Munafò [mailto:[EMAIL PROTECTED] > Sent: Friday, April 02, 2004 9:30 AM > To: Struts Developers List > Subject: RE: Splitting struts-config into multiple jar and read them as > reso urce stream > > > 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?
What do you mean by a subproject? That's not a concept that Struts has. If you mean that you want to divide even modules into multiple jars, rather than just dividing the application into modules, then that just means that we should not always assume a one-to-one mapping between modules and jars. I would suggest that, while the one-to-one mapping would be convenient in many cases, making that a hard-coded assumption would be a mistake anyway. > - not common, but how if a jar need more configs, one for a module and > one for another? Again, I'm not sure I'm understanding you here. A jar file can include pretty much whatever you want it to include. Including a struts-config.xml file in a jar, detecting it automatically, and mapping the jar name to a module make no assumptions, and place no requirements, on what else might be going on in that jar. > 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. I'm not sure what you mean by "this feature" here. Do you mean the ability to auto-configure from a config file in a jar, or do you mean mixing auto-configuration with explicit configuration? Your original message (the one that started this thread) did not indicate any requirement for mixing the two. If you do think you need to be able to do this, could you explain further why you would need it? > 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) No, in my opinion, the default config reader (at least for Struts 1.x) should do exactly what Struts does today. The ability to auto-configure would be provided through an alternative config reader that could be configured (!) if desired. I'm a big fan of having one class do one thing. Adding auto-configuration to the default config reader would mean that that class would be doing more than one thing, because it would also have to be able to behave the way Struts does today, and read the config file paths from web.xml. > 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? Yes, I'm quite sure. It's an alternative config loading scheme, just as the two other alternative config loading schemes I've implemented in the past are alternatives to the default. What we need to do, as Joe emphasised, is make config reading configurable, to allow people to more easily add - and experiment with - alternatives. -- Martin Cooper > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
