Almost done. I added a section on ConfigurationFactory. Will commit soon. On Sun, Sep 13, 2015 at 1:56 PM, Ralph Goers <[email protected]> wrote:
> No, Go for it! > > Ralph > > On Sep 12, 2015, at 9:53 PM, Remko Popma <[email protected]> wrote: > > 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 <[email protected]> > wrote: > >> 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 <[email protected]> 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 <[email protected]> >> 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: [email protected] | [email protected] >>> 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 >>> >> >> > >
