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 Mikael Ståldal <mi...@magine.com> on 2016/08/28 12:38:29 UTC
StatusConfiguration.initialize ()
The method StatusConfiguration.initialize() is invoked from
ConfigurationBuilder.build() and the constructors of XmlConfiguration,
JsonConfiguration and CompositeConfiguration.
Would it make sense if this was instead done in one place, in
Configuration.initialize()? That would make the lifecycle of the
configuration more consistent, first build it and then initialize it.
Re: StatusConfiguration.initialize ()
Posted by Matt Sicker <bo...@gmail.com>.
Agreed on all that.
On 12 September 2016 at 19:03, Remko Popma <re...@gmail.com> wrote:
> I'm actually not that happy with status logging as it works now. The
> status attribute in the configuration file is not helpful in common trouble
> scenarios like the configuration file not being found. Also, status logging
> that happens during the LoggerContext initialization is not displayed. (For
> example, AsyncLogger initialization.)
>
> Users can show this initial status logging by setting system property -
> Dorg.apache.logging.log4j.simplelog.StatusLogger.level=TRACE. This could
> be a more user friendly property name. For troubleshooting purposes,
> something simple like log4j2.debug=true without bothering about the exact
> level may be even better.
> Only after the Configuration has been found and partially processed, the
> status attribute value comes into play. This resets the StatusLogger's
> level, so if a user set the system property to TRACE, but the configuration
> has status=OFF, status logging stops. I can imagine this can surprise
> users.
>
> We should improve the user experience for this.
>
> Sent from my iPhone
>
> On 2016/09/13, at 7:43, Ralph Goers <ra...@dslextreme.com> wrote:
>
> I don’t think moving it is a good idea. The Status Logger is initialized
> as soon as it possibly can be, which is after we have read the attributes
> for the Configuration element. If the call is moved to the initialize
> method then no status logging will occur while the configuration is
> processed.
>
> Ralph
>
> On Sep 12, 2016, at 11:25 AM, Matt Sicker <bo...@gmail.com> wrote:
>
> Anything to reduce duplication of code is great! The Configuration classes
> have quite a bit of duplication right now and are prime candidates for some
> refactoring love.
>
> On 28 August 2016 at 07:38, Mikael Ståldal <mi...@magine.com>
> wrote:
>
>> The method StatusConfiguration.initialize() is invoked from
>> ConfigurationBuilder.build() and the constructors of XmlConfiguration,
>> JsonConfiguration and CompositeConfiguration.
>>
>> Would it make sense if this was instead done in one place, in
>> Configuration.initialize()? That would make the lifecycle of the
>> configuration more consistent, first build it and then initialize it.
>>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
>
>
--
Matt Sicker <bo...@gmail.com>
Re: StatusConfiguration.initialize ()
Posted by Remko Popma <re...@gmail.com>.
I'm actually not that happy with status logging as it works now. The status attribute in the configuration file is not helpful in common trouble scenarios like the configuration file not being found. Also, status logging that happens during the LoggerContext initialization is not displayed. (For example, AsyncLogger initialization.)
Users can show this initial status logging by setting system property -Dorg.apache.logging.log4j.simplelog.StatusLogger.level=TRACE. This could be a more user friendly property name. For troubleshooting purposes, something simple like log4j2.debug=true without bothering about the exact level may be even better.
Only after the Configuration has been found and partially processed, the status attribute value comes into play. This resets the StatusLogger's level, so if a user set the system property to TRACE, but the configuration has status=OFF, status logging stops. I can imagine this can surprise users.
We should improve the user experience for this.
Sent from my iPhone
> On 2016/09/13, at 7:43, Ralph Goers <ra...@dslextreme.com> wrote:
>
> I don’t think moving it is a good idea. The Status Logger is initialized as soon as it possibly can be, which is after we have read the attributes for the Configuration element. If the call is moved to the initialize method then no status logging will occur while the configuration is processed.
>
> Ralph
>
>> On Sep 12, 2016, at 11:25 AM, Matt Sicker <bo...@gmail.com> wrote:
>>
>> Anything to reduce duplication of code is great! The Configuration classes have quite a bit of duplication right now and are prime candidates for some refactoring love.
>>
>> On 28 August 2016 at 07:38, Mikael Ståldal <mi...@magine.com> wrote:
>>> The method StatusConfiguration.initialize() is invoked from ConfigurationBuilder.build() and the constructors of XmlConfiguration, JsonConfiguration and CompositeConfiguration.
>>>
>>> Would it make sense if this was instead done in one place, in Configuration.initialize()? That would make the lifecycle of the configuration more consistent, first build it and then initialize it.
>>>
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>
Re: StatusConfiguration.initialize ()
Posted by Ralph Goers <ra...@dslextreme.com>.
I don’t think moving it is a good idea. The Status Logger is initialized as soon as it possibly can be, which is after we have read the attributes for the Configuration element. If the call is moved to the initialize method then no status logging will occur while the configuration is processed.
Ralph
> On Sep 12, 2016, at 11:25 AM, Matt Sicker <bo...@gmail.com> wrote:
>
> Anything to reduce duplication of code is great! The Configuration classes have quite a bit of duplication right now and are prime candidates for some refactoring love.
>
> On 28 August 2016 at 07:38, Mikael Ståldal <mikael.staldal@magine.com <ma...@magine.com>> wrote:
> The method StatusConfiguration.initialize() is invoked from ConfigurationBuilder.build() and the constructors of XmlConfiguration, JsonConfiguration and CompositeConfiguration.
>
> Would it make sense if this was instead done in one place, in Configuration.initialize()? That would make the lifecycle of the configuration more consistent, first build it and then initialize it.
>
>
>
>
> --
> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
Re: StatusConfiguration.initialize ()
Posted by Matt Sicker <bo...@gmail.com>.
Anything to reduce duplication of code is great! The Configuration classes
have quite a bit of duplication right now and are prime candidates for some
refactoring love.
On 28 August 2016 at 07:38, Mikael Ståldal <mi...@magine.com>
wrote:
> The method StatusConfiguration.initialize() is invoked from
> ConfigurationBuilder.build() and the constructors of XmlConfiguration,
> JsonConfiguration and CompositeConfiguration.
>
> Would it make sense if this was instead done in one place, in
> Configuration.initialize()? That would make the lifecycle of the
> configuration more consistent, first build it and then initialize it.
>
--
Matt Sicker <bo...@gmail.com>