logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Dall ...@eurisco.dk>
Subject RE: API and setLevel / getEffectiveLevel
Date Mon, 25 Mar 2013 16:56:30 GMT
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


Mime
View raw message