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

Reply via email to