2009/9/22 Paul Sharples <[email protected]>:
> Ross
>>
>> I have some concerns about  using PropertiesConfiguration here. I
>> don't see any use of the persistence provided by this class and I
>> don't see any use of the data type handling of the
>> PropertiesConfiguration class. So I wonder if it is necessary to use
>> this class rather than a bog standard properties class?
>>
>>
>
> I originally saw the widgetserver.properties as read-only & had not
> envisaged using the persistence features of PropertiesConfiguration.
> (perhaps wrongly) I agree it would be prudent to add in the mechanism to
> allow a custom properties file to be loaded, so custom/updated values are
> not overwritten on upgrade of the server.

Thanks Paul.

I've done some investigation into this. Being unfamiliar with the
PropertiesConfiguration class I did not realise that it handled
properties differently. In short, if we define, for example,
widget.email.server in the local.properties file that value is then
added to an array with the value provided in the defaults file when
defaults are loaded.

The array features are used in the locale settings so reverting to a
standard properties file is not an option. As a result my original
proposal will not work (without some heavy lifting).

I need to resolve this to proceed with my standalone developer version
of Wookie so I think the best thing to do for 0.8.1 is on first
execution load the default file and save it in the local.properties
location. This will ensure future changes to the properties will be
saved outside of the compiled source space, but will require us to
change properties in both local.properties for testing and
default.properties for distribution.

It's not ideal, but it will work and is easier for users than the
current system (i.e. no need to recompile). Even more importantly it
is very easy to implement. Future iterations may include a property
handling class that does it all seamlessly.

I'll provide a patch ASAP.

Ross

Reply via email to