Actually, that still leaves the problem of specifying a Configuration for
the DefaultConfigurationLayout. PatternLayout is final right now, and the
default pattern is "%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} -
%msg%n".On 25 May 2014 19:03, Matt Sicker <[email protected]> wrote: > 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]> > -- Matt Sicker <[email protected]>
