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] 
> <mailto:[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] 
> <mailto:[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] 
> <mailto:[email protected]>> wrote:
> No, Go for it!
> 
> Ralph
> 
>> On Sep 12, 2015, at 9:53 PM, Remko Popma <[email protected] 
>> <mailto:[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>
>> 
> 
> 
> 
> 
> 
> 
> -- 
> Matt Sicker <[email protected] <mailto:[email protected]>>

Reply via email to