Ted Husted wrote:
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>
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.
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.)
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.
Don
-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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
