So why wouldn't you create a custom Configuration that merges the configuration file and database settings? That avoids all the problems I mention below.
Ralph On Mar 25, 2013, at 6:23 AM, Jacob Dall wrote: > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
