PropertyManager
I've checked the PropertyManager into the 'rearchitecture' branch and will check in the javadocs next. There's a lot the PropertyManager can do, but probably for now the simplest approach is the best. It looks and behaves like setting or getting properties via System, except it sources the properties from a range of places. The default is an XML configuration file, but users can plugin different implementations (e.g., a remote property service).
If you look at a cut-down version of a JBossTS property file:
<?xml version="1.0" encoding="UTF-8"?> <transaction-service> <properties depends="common" name="arjuna"> <!-- Transaction Reaper Timeout (default is 120000 microseconds). --> <property name="com.arjuna.ats.arjuna.coordinator.txReaperTimeout" value="120000"/> <!-- Transaction Reaper Mode, can be: NORMAL or DYNAMIC (default is NORMAL). --> <property name="com.arjuna.ats.arjuna.coordinator.txReaperMode" value="NORMAL"/> </properties> <properties depends="arjuna" name="recoverymanager"> <!-- Properties used only by the RecoveryManager. --> <!-- Periodic recovery settings. Time values in this section are in seconds. --> <!-- Interval in seconds between initiating the periodic recovery modules. Default is 120 seconds. --> </properties> <properties name="common"> <!-- CLF 2.0 properties --> <property name="com.arjuna.common.util.logging.DebugLevel" type="System" value="0x00000000"/> <property name="com.arjuna.common.util.logging.FacilityLevel" type="System" value="0xffffffff"/> <property name="com.arjuna.common.util.logging.VisibilityLevel" type="System" value="0xffffffff"/> <property name="com.arjuna.common.util.logger" type="System" value="log4j"/> </properties> <properties depends="arjuna" name="txoj"> <!-- (default is LockStore of installation - must be writeable!) --> <!-- <property name="com.arjuna.ats.txoj.lockstore.lockStoreDir" value="LockStore"/> --> </properties> </transaction-service>
All properties are grouped within sections and individual properties by . If you look at some you'll see that they may be named and may have a depends value, which relates to another section. This tells the PropertyManager to load the depends section first. A property value may be overridden by a dependant section, but the PropertyManager remembers the hierarchy, so if you want to you can inspect and change the lower level value and the PropertyManager can be used to preserve these changes if the values are written back out to the source location.
As I said, there's a lot more in the PropertyManager than we need at the moment, but I think we'll get there fairly soon.
I want to put all deployment configuration options within a property file like the one above. I don't know yet whether that will cover things like the DOM trees we use for connecting listeners with actions. I suspect not: different things.
