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>
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/**>
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/**>
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/**>
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?**>
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/**>
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?revision=1491090&view=markup>
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>
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
