logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remko Popma <remko.po...@gmail.com>
Subject Re: Programmatic configuration
Date Sun, 13 Sep 2015 04:53:56 GMT
Understood, so you would not want to remove the first example. Would you
object to moving the section on the new Configuration Builder API to the
top of the page to make it more prominent?

On Sun, Sep 13, 2015 at 1:19 PM, Ralph Goers <ralph.goers@dslextreme.com>

> Well, I view the first example as a valid use case. Some folks might want
> to allow for a flexible configuration using XML but make sure there are a
> few configuration elements that are always present that can’t be removed.
> Of course, we might be able to solve that by addressing LOG4J2-494 and
> adding support for composite configurations.
> Ralph
> On Sep 12, 2015, at 8:24 PM, Remko Popma <remko.popma@gmail.com> wrote:
> Thanks for bringing this up. Now that we have a configuration builder API
> that is just as powerful and flexible as XML configuration, we should
> advertise this as THE main way for users to programatically configure
> Log4j.
> The Custom Configuration manual page ("Extending Log4j Configuration" in
> the side nav) mentions the configuration builder API as just one of the
> alternatives for programatically configuring log4j 2. I propose we take a
> stronger stance and remove the older example (the first one on the page)
> that extends XmlConfiguration. This older example uses the builders and
> factory methods to manually add Loggers/Appenders; I would like to
> discourage direct use of the builders and factory methods.
> The only programmatic configuration use case that may not be solved (yet)
> by the configuration builder API is the ability to modify the current
> configuration (while the application is running). Some applications want to
> change log levels or add appenders on the fly. Can this be done with the
> configuration builder API?
> By the way, it looks like the FAQ page now has two entries for the same
> question:
> * How do I change a logger's level in code?
> * How do I set a logger's level programmatically?
> On Sunday, September 13, 2015, Gary Gregory <garydgregory@gmail.com>
> wrote:
>> So here we are WRT programmatic configuration, users' options are:
>> - The new builder API. Most flexible, not 100% type-safe, a typo in a
>> property name can mess you up.
>> - The sprinkling of Builder classes. Easy to code against (fluent),
>> type-safe, a bit brittle but less so than factory methods (order of calls
>> does not patter like method param order does).
>> - The factory methods. Most difficult to code against (long param list),
>> most brittle.
>> My questions:
>> - Should we remove Builder classes?
>> - Should we replace factory methods with Builder classes? Seems like a
>> lot of work.
>> - Should we accept/encourage contributors to submit Builder patches?
>> Right now, I kind of want 2.4 out ASAP and see what people use.
>> Thoughts?
>> Gary
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition
>> <http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory

View raw message