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