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-defa
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.
-
On 11/21/06, Don Brown <[EMAIL PROTECTED]> wrote:
>
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
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 lo
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
So where are we now, then? Have the settings been moved to
struts-default.xml? Are there any other things that need to be done here?
Don
Ted Husted wrote:
On 11/21/06, Don Brown <[EMAIL PROTECTED]> wrote:
However, having default.properties override struts.xml is definitely not
what we want
The real solution is to split out the loading of default.properties and
struts.properties into two configuration provider instances.
It is puzzling why copying over the settings to struts-default.xml would
break the tests... What errors are you seeing?
Don
Ted Husted wrote:
On 11/21/06, Don
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 obje
On 11/21/06, Don Brown <[EMAIL PROTECTED]> wrote:
However, having default.properties override struts.xml is definitely not
what we want
Never mind on that score. It seems to be working now. I turned
DynamicMethodInvocation off in the application's struts.xml and now it
is in fact disabled.
-Te
On 11/21/06, Don Brown <[EMAIL PROTECTED]> wrote:
It should work just fine, as should the rest of the properties. Still,
before we move them, perhaps we should resolve what to do with their
comments.
My first preference would be to enumerate all the settings in
StrutsConstants, where we can us
Ted Husted wrote:
On 11/21/06, Don Brown <[EMAIL PROTECTED]> wrote:
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 name
Ah, I believe I figured it out. It actually works exactly how we want
it. Why we see a problem is because of this devMode setting. The
problem is XWork expects a "devMode" property, but Struts wants
"struts.devMode". When we load default.properties, if we detected a
"struts.devMode" propert
Yeah, I agree. There are some cool things we can do with namespaces,
but there is no need to hurry and they should be well thought out. I
also think your plan of putting the docs in the Javadocs and some small
hint in the xml makes sense.
+1's all around :)
Don
Ted Husted wrote:
On 11/21
On 11/21/06, Ted Husted <[EMAIL PROTECTED]> wrote:
# struts.devMode = false
devMode was just an example. The same thing seems to happen with most
any setting in default.properties. Having them in both places doesn't
cause a build error, but I didn't test to see if struts-default.xml
supercedes
14 matches
Mail list logo
