When I was playing with the settings ast night, I wasn't able to move most settings out of default.properties at all. As soon as I did, most of the tests began to fail. Thats as far as I got.
WRT inline documentation, for XML perhaps we could include remarks as the body of the element and have loader pick it up from there. <constant name="struts.devMode" value="false> When struts.devMode is set to true, Struts will act much more friendly for developers. This includes setting: struts.i18n.reload = true; struts.configuration.xml.reload = true; and raising various debug or ignorable problems to errors. For example: normally a request to foo.action?someUnknownField=true should be ignored (given that any value can come from the web and it should not be trusted). However, during development, it may be useful to know when these errors are happening and be told ofthem right away. </constant> Ideally, I'm thinking we should only use default.properties to set properties that concern loazding the XML documents, like ### A list of configuration files automatically loaded by Struts struts.configuration.files=struts-default.xml,struts-plugin.xml,struts.xml Though, the last time I tried to use the property in the ActionMapping, it didn't work. We had to hardcode it to prime the pump (for the tests?). Dispatcher.java (145) private static final String DEFAULT_CONFIGURATION_PATHS = "struts-default.xml,struts-plugin.xml,struts.xml"; Though, maybe this setting could be injected now, so that we don't recite the same fact twice. (I suppose we should also rename the Dispatcher field to match the setting name.) -Ted. On 11/21/06, Don Brown <[EMAIL PROTECTED]> wrote:
The only disadvantage of including the settings in struts-default.xml file is we lose the comments above each setting. A recent change I did was to plug in a Properties file loader that not only remembers line numbers but also comments above an entry. These comments are saved in Location objects so that debugging and error logs later will include them. However, having default.properties override struts.xml is definitely not what we want...We could also split up the LegacyPropertiesLoader to only load one at a time (default.properties and struts.properties). Don Ted Husted wrote: > I'm thinking that a problem I having with setting properties in the > struts.xml (see r477484) may be because the default properties file is > being loaded after the XML configurations, and overriding my changes. > > In any event, I'm going to try moving the default.properties settings > to the struts-default.xml, so that everything is configured in one > place. > > -Ted. > > On 11/20/06, Ted Husted <[EMAIL PROTECTED]> wrote: >> Now that we can configure constants via the XML files >> >> * http://struts.apache.org/2.x/docs/constant-configuration.html >> >> is using the struts.properties deprecated? >> >> Or, would there be other valid reasons to keep it around? >> >> -T.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
