I understand your concern and what you are trying to achieve. My only concern about setLevel / getEffectiveLevel not being available in the API is that someone should 'suddenly' remove these methods from the implementation, leaving programmers using these with a BIG issue. What are the risk of methods disappearing from the implementation, once put into action?
FYI, in our particular case we use the configuration file to define logger "types" but not logger levels. Simply because we have like a gazillion (greatly exaggerated, of course, but you get the idea) of each type of logger, that depends on how the system is used. Log levels are instead stored in a database. Thanks Jacob -----Original Message----- From: Ralph Goers [mailto:[email protected]] Sent: 22. marts 2013 16:53 To: Log4J Developers List Subject: Re: API and setLevel / getEffectiveLevel On Mar 22, 2013, at 3:38 AM, Jacob Dall wrote: > Dear "Log4j 2" developers > > In the "Migration from Log4j 1.x" manual, "Converting to the Log4j 2 API" > clause, it is written: > > "4. Calls to logger.setLevel or similar methods are not supported in the API. > Applications should remove these. Equivalent functionality is provided in the > Log4j 2 implementation classes but may leave the application susceptible to > changes in Log4j 2 internals." > > If an application needs to set the levels programmatically, it probably does > so for a good reason. One can't "just remove these", if there is nothing to > put instead. > > Why is that functionality not available from the API? > > Would it cost many tears and a lot of sweat to add it? There are several reasons. 1. The API is for users of Log4j who want to log events and who want guarantees that the API they are coding to will remain stable. Once you start programmatically modifying the logging configuration you are now outside the bounds of that safe API and into the implementation. This was one of the fundamental problems with Log4j 1 and is one of the reasons Ceki created SLF4J and Logback. 2. Log4j has thread safety issues and performance issues. Many of these are because the API exposes things that cause these problems. 3. If you programmatically modify a log level and then the external configuration is changed your programmatic change will be lost. This is not a show stopper but anyone doing this needs to be aware the change isn't permanent. 4. Applications that want to programmatically modify the configuration need to do it in a manner compatible with the implementation. Log4j 2 allows several ways for the configuration to be modified. Just not through the public API. Ralph --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
