I saw that, but there's no IDE autocomplete for it. As a huge abuser of autocomplete, I feel like this might be worthwhile. I'll play around a bit before committing to a huge task like that.
On 14 October 2015 at 21:37, Ralph Goers <[email protected]> wrote: > Before you expend the effort you might want to take a look at the new > ConfigurationBuilder that was introduced in 2.4. Maybe you will decide it > isn’t worth the effort. To be honest, I just created some new plugins for > scripting and actually considered using builders for them but it wasn’t > clear to me how to implement that so I fell back to using the factory > pattern. > > Ralph > > On Oct 14, 2015, at 7:31 PM, Matt Sicker <[email protected]> wrote: > > Reviving what I thought I read about a while ago. I'm willing to go > through all the plugin classes and add consistent builder classes. As it's > been a while since I've worked on Log4j, this would be a good place for me > to work again while I get familiar with the thousand new features. :) > > On 13 September 2015 at 14:36, Remko Popma <[email protected]> wrote: > >> 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 >>>>>> >>>>> >>>>> >>>> >>>> >>> >> > > > -- > Matt Sicker <[email protected]> > > > -- Matt Sicker <[email protected]>
