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] > <mailto:[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] >> <mailto:[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] >> <mailto:[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 <http://garygregory.wordpress.com/> >> Home: http://garygregory.com/ <http://garygregory.com/> >> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory> >
