On 11/21/06, Don Brown <[EMAIL PROTECTED]> wrote:
> <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> Yeah, this would work, as would a new namespace, using XML comments, or perhaps something else. I was just pointing out that we'll need to implement something like what works for properties now.
I don't know what "a new namespace" means. An advantage of actually putting the remarks in the element is that they can be parsed by anything that can read XML. What we've started to do with properties comments is a neat idea, and we should elevate it to a first-class feature with a clean implementation.
> 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.) Yeah, actually, this setting doesn't exist anymore. This is because the list of xml files to load can't be in the xml files to load.... So, there is an web.xml init param you can set if you want to override this. Otherwise, the list in that Dispatcher constant will be used.
Well, it might be otherwise ignored, but a "struts.configuration.files" setting does exists in the default.properties. Is there a cannonical list of settings expressed as Java code? What determines whether a "setting exists"? -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
