Hi Glen, I'm in favour of simplifying the property management of JSPWiki. The default_jspwiki.properties file is indeed unused (so far as I know). Projects tend to get more complicated over time rather than the converse, so if you think this is a substantial improvement and simplifies things then I'm all for it.
My only reservation is that the work I've done so far on simplifying the WikiEngine (via the EntityManager idea) overlaps a bit with this, in that there are a couple of places where manager implementations are actually specified in jspwiki.properties. The EntityManager actually extracts those to a different place, i.e., out of jspwiki.properties. So in the sense that what I'm proposing simplifies property management a bit, what you're proposing is orthogonal to the EntityManager work. Which, admittedly, is not part of any workflow or plan, just something I'm trying to build and donate to the project. We (Neocortext) do have PropertyManager and PropertyUtils classes that perform certain things that might be helpful, dunno. The latter has the ability to have a *.properties file that sits in the same directory as its class file, which cascades against the application and System properties (in descending priority order). So you can set class-level defaults, permit application-level overrides, over System properties. With some juggling we've also put System properties at the top of the priority tree so that command-line System properties override the class properties. But it sounds like that wouldn't be particularly valuable here and may make things more complicated. But in the sense that JSPWiki's property management could use some cleanup, +1. Ichiro PS. Things have slowed down at this end due to a very large project and some other time constraints that have hit lately, but the EventManager still remains on our agenda (since it is part of a larger project). On Wed, Aug 7, 2013 at 3:43 PM, Glen Mazza <glen.ma...@gmail.com> 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 > >
