You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Jacob Dall <jd...@eurisco.dk> on 2013/03/22 11:38:09 UTC
API and setLevel / getEffectiveLevel
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?
Kind regards
Jacob Dall
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: API and setLevel / getEffectiveLevel
Posted by Jacob Dall <jd...@eurisco.dk>.
Well, basically because I haven't thought of doing it that way - probably because it was not an issue with the currently used logger core to do it the way we did ;)
I'll have to look further into it, but I like the idea - thanks for sharing it.
Jacob
-----Original Message-----
From: Ralph Goers [mailto:ralph.goers@dslextreme.com]
Sent: 25. marts 2013 14:31
To: Log4J Developers List
Subject: Re: API and setLevel / getEffectiveLevel
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:ralph.goers@dslextreme.com]
> 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: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: API and setLevel / getEffectiveLevel
Posted by Ralph Goers <ra...@dslextreme.com>.
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:ralph.goers@dslextreme.com]
> 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: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: API and setLevel / getEffectiveLevel
Posted by Jacob Dall <jd...@eurisco.dk>.
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:ralph.goers@dslextreme.com]
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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: API and setLevel / getEffectiveLevel
Posted by Ralph Goers <ra...@dslextreme.com>.
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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org