You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Matt Sicker <bo...@gmail.com> on 2015/10/15 04:31:12 UTC
Re: Programmatic configuration
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 <re...@gmail.com> 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 <re...@gmail.com>
> wrote:
>
>> Almost done. I added a section on ConfigurationFactory. Will commit soon.
>>
>> On Sun, Sep 13, 2015 at 1:56 PM, Ralph Goers <ra...@dslextreme.com>
>> wrote:
>>
>>> No, Go for it!
>>>
>>> Ralph
>>>
>>> On Sep 12, 2015, at 9:53 PM, Remko Popma <re...@gmail.com> 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 <ralph.goers@dslextreme.com
>>> > 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 <re...@gmail.com> 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 <ga...@gmail.com>
>>>> 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: garydgregory@gmail.com | ggregory@apache.org
>>>>> 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 <bo...@gmail.com>
Re: Programmatic configuration
Posted by Matt Sicker <bo...@gmail.com>.
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 <ra...@dslextreme.com> 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 <bo...@gmail.com> 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 <re...@gmail.com> 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 <re...@gmail.com>
>> wrote:
>>
>>> Almost done. I added a section on ConfigurationFactory. Will commit soon.
>>>
>>> On Sun, Sep 13, 2015 at 1:56 PM, Ralph Goers <ralph.goers@dslextreme.com
>>> > wrote:
>>>
>>>> No, Go for it!
>>>>
>>>> Ralph
>>>>
>>>> On Sep 12, 2015, at 9:53 PM, Remko Popma <re...@gmail.com> 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 <
>>>> ralph.goers@dslextreme.com> 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 <re...@gmail.com>
>>>>> 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 <ga...@gmail.com>
>>>>> 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: garydgregory@gmail.com | ggregory@apache.org
>>>>>> 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 <bo...@gmail.com>
>
>
>
--
Matt Sicker <bo...@gmail.com>
Re: Programmatic configuration
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <bo...@gmail.com> 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 <remko.popma@gmail.com <ma...@gmail.com>> 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 <remko.popma@gmail.com <ma...@gmail.com>> wrote:
> Almost done. I added a section on ConfigurationFactory. Will commit soon.
>
> On Sun, Sep 13, 2015 at 1:56 PM, Ralph Goers <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
> No, Go for it!
>
> Ralph
>
>> On Sep 12, 2015, at 9:53 PM, Remko Popma <remko.popma@gmail.com <ma...@gmail.com>> 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 <ralph.goers@dslextreme.com <ma...@dslextreme.com>> 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 <remko.popma@gmail.com <ma...@gmail.com>> 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 <garydgregory@gmail.com <ma...@gmail.com>> 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: garydgregory@gmail.com <> | ggregory@apache.org <>
>>> 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 <boards@gmail.com <ma...@gmail.com>>