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 > >
