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] > <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>
