Umm, I really would *not* want to go that route, there's no practical
benefit to providing both options (never has been on Roller for over a
decade now), it would raise unnecessary confusion among users, and it
would be cumbersome to code.
With my proposed change, you are never going to alter the
jspwiki.properties file again (unless you manually go in and tweak it,
which you should never need to do anyway). You can only override it
with another file, with just those handful of values you wish to
override. If you don't override it, then jspwiki.properties in the WAR
defaults.
What I'm proposing is not just how Roller does things but precisely how
Apache Karaf does too, you alter a custom file that overrides the
default, and they leave a blunt comment in the default file to leave it
alone and alter the custom file instead.
Glen
On 08/08/2013 08:32 AM, Juan Pablo Santos Rodríguez wrote:
Hi,
one quick note, if I recall correctly, "-Djspwiki.propertyfile" is used to
load the main jspwiki.properties from outside the war, so it should be able
to coexist with "-Djspwiki.custom.config", something like:
- jspwiki.properties, loaded first, from war (unless -Djspwiki.propertyfile
is given)
- jspwiki-custom.properties, loaded afterwards, from classpath (unless
-Djspwiki.custom.config is given)
br,
juan pablo
On Thu, Aug 8, 2013 at 2:14 PM, Glen Mazza <[email protected]> wrote:
Yes, I like -Djspwiki.custom.config too. I'll see what I can do for
logging.
Glen
On 08/08/2013 08:01 AM, Harry Metske wrote:
Changing the propname to something else would not be a problem,
"-Djspwiki.custom.config" is fine.
What I meant is that it should be very clear _how_ these things play
together, both in documentation and logging.
kind regards,
Harry
On 8 August 2013 13:56, Glen Mazza <[email protected]> wrote:
Yes, [#1] would be the [3] I mentioned below. But would it be a problem
if I renamed our "-Djspwiki.propertyfile" setting to "-Djspwiki.custom.**
**propertyfile"
(or "-Djspwiki.custom.config" similar to Roller) as it's technically no
longer a replacement of the jspwiki.properties file (which will always be
in the WAR) but an overlay of it (same thing, so long as your overlay
has a
value for every property in the jspwiki.properties file, which current
-Djspwiki.propertyfiles have to do anyway as they fully replace that
file.)
I don't see this as a backwards compatibility issue as it's just a
command-line setting.
Glen
On 08/07/2013 08:10 AM, Harry Metske wrote:
from an administration perspective (part of my daily live) I consider
having configuration separate from binaries a must-have.
So +1 on this, it should get easier to deploy (the 100% same)
JSPWiki.war
everywhere and having a per-environment small "override" property file
that
adapts the JSPWiki instance to the environment.
I would like to see proper logging on property handling so we can see
which
property gets loaded from where, and what the final property values are
going to be active.
(and, similar to what Ichiro already mentioned, it should play nice with
JSPWiki System property mechanism, see [#1].
[#1]
https://issues.apache.org/****jira/browse/JSPWIKI-568<https://issues.apache.org/**jira/browse/JSPWIKI-568>
<https:**//issues.apache.org/jira/**browse/JSPWIKI-568<https://issues.apache.org/jira/browse/JSPWIKI-568>
kind regards,
Harry
On 7 August 2013 05:43, Glen Mazza <[email protected]> wrote:
Hi Team,
Apache Roller maintains two configuration files, a roller.properties[1]
which sits within the war, filled with defaults and never needs
modification (although a user can alter it if he wishes, it will work),
and
a roller-custom.properties file[2] which is placed in the classpath
($CATALINA_HOME/lib for Tomcat, corresponding folders for JBoss or
GlassFish.) For any value you put in roller-custom.properties, it will
overwrite what is in roller.properties in the WAR. So you only need
the
values in the custom file that you're actually overriding, making it
very
short and simple. And if you don't use a roller-custom.properties, all
of
the defaults in the WAR will prevail.
You can keep deploying new versions of Roller.war to your servlet
container while never needing to re-configure either roller.properties
or
roller-custom.properties, re-opening WARs, etc. as the
roller-custom.properties still sitting in $CATALINA_HOME/lib
automatically
is used--this is very convenient during development when the WARs
frequently get updated. Same with JUnit and Selenium testing, we don't
alter the roller.properties but just place the
roller-custom.properties[2]
in the test classpath under src/test/resources (if you have multiple
config
files, you can change the custom file name via setting a system
property[3]). All this is handled by the WebloggerConfig[4] class,
which
first reads in roller.properties and the overwrites any values from
roller-custom.properties.
[1]
http://svn.apache.org/viewvc/******roller/trunk/app/src/main/****<http://svn.apache.org/viewvc/****roller/trunk/app/src/main/**>
<http://svn.apache.org/**viewvc/**roller/trunk/app/src/**main/**<http://svn.apache.org/viewvc/**roller/trunk/app/src/main/**>
resources/org/apache/roller/******weblogger/config/roller.**
properties?view=markup<http://****svn.apache.org/viewvc/**roller/**<http://svn.apache.org/viewvc/roller/**>
trunk/app/src/main/resources/****org/apache/roller/weblogger/****
config/roller.properties?view=****markup<http://svn.apache.**
org/viewvc/roller/trunk/app/**src/main/resources/org/apache/**
roller/weblogger/config/**roller.properties?view=markup<http://svn.apache.org/viewvc/roller/trunk/app/src/main/resources/org/apache/roller/weblogger/config/roller.properties?view=markup>
<
http://svn.apache.org/viewvc/******roller/trunk/app/src/main/****<http://svn.apache.org/viewvc/****roller/trunk/app/src/main/**>
<http://svn.apache.org/**viewvc/**roller/trunk/app/src/**main/**<http://svn.apache.org/viewvc/**roller/trunk/app/src/main/**>
resources/org/apache/roller/******weblogger/config/roller.**
properties?revision=1511052&******view=markup<http://svn.**apache.<http://svn.apache.>
**
org/viewvc/roller/trunk/app/****src/main/resources/org/apache/****
roller/weblogger/config/****roller.properties?revision=**
1511052&view=markup<http://**svn.apache.org/viewvc/roller/**
trunk/app/src/main/resources/**org/apache/roller/weblogger/**
config/roller.properties?**revision=1511052&view=markup<http://svn.apache.org/viewvc/roller/trunk/app/src/main/resources/org/apache/roller/weblogger/config/roller.properties?revision=1511052&view=markup>
[2]
http://svn.apache.org/viewvc/******roller/trunk/app/src/test/****<http://svn.apache.org/viewvc/****roller/trunk/app/src/test/**>
<http://svn.apache.org/**viewvc/**roller/trunk/app/src/**test/**<http://svn.apache.org/viewvc/**roller/trunk/app/src/test/**>
resources/roller-custom.******properties?view=log<http://**
svn.apache.org/viewvc/roller/****trunk/app/src/test/resources/****<http://svn.apache.org/viewvc/roller/**trunk/app/src/test/resources/**>
roller-custom.properties?view=****log<http://svn.apache.org/**
viewvc/roller/trunk/app/src/**test/resources/roller-custom.**
properties?view=log<http://svn.apache.org/viewvc/roller/trunk/app/src/test/resources/roller-custom.properties?view=log>
[3]
http://svn.apache.org/viewvc/******roller/trunk/app/pom.xml?**<http://svn.apache.org/viewvc/****roller/trunk/app/pom.xml?**>
**<http://svn.apache.org/viewvc/****roller/trunk/app/pom.xml?**<http://svn.apache.org/viewvc/**roller/trunk/app/pom.xml?**>
revision=1511052&view=markup#******l460<http://svn.apache.org/****<http://svn.apache.org/**>
viewvc/roller/trunk/app/pom.****xml?revision=1511052&view=****
markup#l460<http://svn.apache.**org/viewvc/roller/trunk/app/**
pom.xml?revision=1511052&view=**markup#l460<http://svn.apache.org/viewvc/roller/trunk/app/pom.xml?revision=1511052&view=markup#l460>
[4]
<http://svn.apache.org/viewvc/******roller/trunk/app/src/main/****<http://svn.apache.org/viewvc/****roller/trunk/app/src/main/**>
<http://svn.apache.org/**viewvc/**roller/trunk/app/src/**main/**<http://svn.apache.org/viewvc/**roller/trunk/app/src/main/**>
java/org/apache/roller/******weblogger/config/****
WebloggerConfig.java?revision=
**1491090&view=markup<http://****svn.apache.org/viewvc/roller/****<http://svn.apache.org/viewvc/roller/**>
trunk/app/src/main/java/org/****apache/roller/weblogger/**
config/WebloggerConfig.java?****revision=1491090&view=markup<h**
ttp://svn.apache.org/viewvc/**roller/trunk/app/src/main/**
java/org/apache/roller/**weblogger/config/**
WebloggerConfig.java?revision=**1491090&view=markup<http://svn.apache.org/viewvc/roller/trunk/app/src/main/java/org/apache/roller/weblogger/config/WebloggerConfig.java?revision=1491090&view=markup>
http://**svn.apache.org/****viewvc/roller/**trunk/app/src/****<http://svn.apache.org/**viewvc/roller/**trunk/app/src/**>
main/java/org/**<http://svn.**apache.org/viewvc/roller/****
trunk/app/src/main/java/org/**<http://svn.apache.org/viewvc/roller/**trunk/app/src/main/java/org/**>
**>
apache/roller/weblogger/******config/WebloggerConfig.java?****
**view=markup<
http://svn.apache.**org/**viewvc/roller/trunk/app/**
src/main/java/org/apache/****roller/weblogger/config/**
WebloggerConfig.java?view=****markup<http://svn.apache.org/**
viewvc/roller/trunk/app/src/**main/java/org/apache/roller/**
weblogger/config/**WebloggerConfig.java?view=**markup<http://svn.apache.org/viewvc/roller/trunk/app/src/main/java/org/apache/roller/weblogger/config/WebloggerConfig.java?view=markup>
I'd like to do the same thing with Apache JSPWiki, modify our own
PropertyReader.java to accept a new jspwiki-custom.properties file.
Also,
to get rid of the mostly forgotten and empty /ini/default_jspwiki.****
properties
and put whatever default values there into jspwiki.properties (unless
where
the latter has already overridden those properties.) Basically,
jspwiki.properties will assume the role of default_jspwiki.properties
and
we'll have a new optional jspwiki-custom.properties that will not be in
the
WAR at all (you don't want to have it in the WAR as it would get read
over
what's in $CATALINA_HOME/lib, and if you had something to put in
jspwiki-custom.properties in the WAR you'd just use jspwiki.properties
anyway.) Backwards compatibility would not be an issue, as you'd just
take
your jspwiki.properties file from the old WAR and can still insert it
into
the new WAR or just rename it jspwiki-custom.properties and put it on
the
external classpath. WDYT?
Regards,
Glen
