Appenders without layout

[Ivan Habunek <iv...@gmail.com>]

Hi all,

It's not very clearly defined what an appender should do when it
requires a layout, but the layout is not specified in the
configuration.

Currently, most appenders will simply not append if the layout is not
provided. However, they will not report a warning and/or close
themselves.

I can see two possible solutions:
a) fall back to a default layout (e.g. LoggerLayoutSimple)
b) report a warning and close the appender

I am leaning towards option a) since I don't see any dangerous
consequences of this decision.

What do you think?

Regards,
Ivan

Re: Appenders without layout

[Ivan Habunek <iv...@gmail.com>]

On 9 September 2011 13:18, Christian Grobmeier <gr...@gmail.com> 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

Re: Appenders without layout

[Christian Grobmeier <gr...@gmail.com>]

> I can see two possible solutions:
> a) fall back to a default layout (e.g. LoggerLayoutSimple)
> b) report a warning and close the appender
>
> I am leaning towards option a) since I don't see any dangerous
> consequences of this decision.
>
> What do you think?

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 ;-)

Thanks for digging that out!

Cheers
Christian

>
> Regards,
> Ivan
>



-- 
http://www.grobmeier.de