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]
