Agreed on all that.

On 12 September 2016 at 19:03, Remko Popma <remko.po...@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 <ralph.go...@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 <boa...@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.stal...@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 <boa...@gmail.com>
>
>
>


-- 
Matt Sicker <boa...@gmail.com>

Reply via email to