That sounds like a better idea. Let me see how well it works out in code.
On 25 May 2014 18:52, Remko Popma <[email protected]> wrote: > Perhaps DefaultConfigurationLayout would be a better name for such alayout, > actually. > > > On Monday, May 26, 2014, Remko Popma <[email protected]> wrote: > >> How about having a DefaultLayout for use *only* by DefaultConfiguration? >> The formatters used by this layout can be hard-coded: level, timestamp, >> message. >> Thoughts? >> >> Sent from my iPhone >> >> On 2014/05/26, at 8:38, Matt Sicker <[email protected]> wrote: >> >> So DefaultConfiguration creates a PatternLayout, but PatternLayout takes >> a Configuration. I thought it would help prevent NPEs using a >> DefaultConfiguration as the default, but then upon trying that, I found >> myself in an infinite recursion of constructors! >> >> In order to provide a default, we have a few options: >> >> 1. Use NullConfiguration by default. Problem is, this basically means >> "ignore all logging calls". >> >> 2. Lazily create the DefaultConfiguration if configuration is null at >> build() time. >> >> 3. Leak "this" from the DefaultConfiguration constructor into the >> PatternLayout used for the default ConsoleAppender which is used as the >> default appender on the root logger. It's not pure, but sometimes you do >> need to leak an object before it's been fully constructed. >> >> 4. Add another attribute to disable setting a Configuration. I don't like >> this option as it introduces extra complexity and doesn't solve the problem >> of having a null config (and not a NullConfiguration). >> >> Right now, I'm leaning toward 2 and 3 combined. >> >> -- >> Matt Sicker <[email protected]> >> >> -- Matt Sicker <[email protected]>
