I'm done with the documentation changes for programmatic configuration. Phew! I have nothing else in the pipeline for 2.4, and I also see no blockers in Jira.
On Mon, Sep 14, 2015 at 3:57 AM, Remko Popma <[email protected]> wrote: > 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 >>>> >>> >>> >> >> >
