I've been getting wary myself of using properties for this kind of work, since it a) implies a start/restart routine to bring in changes, and b) leaves a proper restart in the hands of correct editing. My recent work with a lot of Sun ONE products in particular makes me wonder if XML-everything for config files is such a cool idea.
Yes. The Charity Technology Trust raffle engine (see eg the current Royal British Legion raffle) uses a similar approach to define validation rules for various card types. As you don't see new types every day or even every year, the problems you rightly describe aren't very important in this case.
Originally posted by Michael Ernest:
I had thought of a hashtable too, but never having used the approach myself I didn't mention it. Have you used this approach, Peter?
For our in-house controller, we implemented an auto-refresh by checking the configuration file timestamp every X seconds. This will read the new file and parse it into a new Configuration object. If an exception is thrown during the parsing and validation phase, this is logged and the new Configuration is discarded, leaving the old, working, configuration in its place. Only when the new configuration is valid it is actually installed.
Originally posted by Blake Minghelli:
If you don't want to restart in order to change handlers then you could consider [...] an "auto-refreshing" properties object.
However, that would still leave you with your concern about improper editing...
Originally posted by James Bowen:
I thought that an 'if' statement would be hard to maintain if new rules came along,
WHAT is your favorite color? Blue, no yellow, ahhhhhhh! Tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koophttps://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton