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>