>> 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. I mean exactly that! I've only the default module divided into multiple jars, each with all that a specific function/unit (of our projects) needs: classes, xsl, xsd, xml, config, ... . In other words: each jar is not a struts-module, but a 'sub-unit', a 'sub-project'.. But even a non default module could be divided into multiple jars. So, in my opinion, having jar's name correspond to a module name would have to be avoided. >> - 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. Simply this: if a jar (not a struts-module) needs to be part of two or more modules, then I need more struts-config.xml (one for each module) inside it. >> 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? By "this feature" I mean the thread subject: read configs from jar. Starting from your point (mixing auto-configuration with explicit configuration), I wrote my thoughts. Anyway, you are right, I've no requirement about mixing the two. So, if no one else need it (mixing the two) you can forget 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. My question here was not about extending default config for auto-configuration, but 'simply': why not extend default config for read files inside jar, as now struts does for /WEB-INF/struts-config.xml? It needs no changes in the way struts works today, only the ability to read a file explicitly listed in the config init parameter from a place, the jar, where now cannot be read. >> 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 Think of this: - the refactoring of struts configuration is done and struts 2.x (or 3.x) is out. Someone needs to read a config file from jar. Instead of modifing web.xml and add META-INF/struts-config.xml to the init parameter, a new class should be written extending the right configurator interface. Then this class should be declared in web.xml or in another file. Then..I don't know now. I'm still not so sure, but don't worry ;-) Filippo > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
