On 9 September 2011 13:18, Christian Grobmeier <[email protected]> wrote: > I agree with a) is the better solution. > Logging should never break an application and should always do what is > expected. If one wants to log, it should log somehow ;-)
Good. We are in agreement. To continue, I have another design issue: appender parameters. :) Firstly, I'm considering calling them "options" instead of "configurable parameters". It's much shorter, and it will agree with naming of the activateOptions() method. This is a documentation issue, should not affect any code. Second issue concerns getters and setters for options. Currently, some setters parse the options. I'm not sure this is the best choice, since one would not expect a setter to trigger an error (which may happen once we add error reporting). My porposal is to make setters simple (java style). They just save the value that's passed to them into a private member variable. Then, when activateOptions() is called it parses the options and triggers warnings if needed. A penny for your thoughts. Regards, Ivan
