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
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/**
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?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/**
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?**
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/**
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/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
