Well, you can actually do that. It is just not my number one recommendation
:-) I'm pretty sure I have answered how to do that a few times. It just needs
to be documented.
The actual code to do this is
LoggerContext ctx = (LoggerContext) LogManager.getContext(false);
Configuration config = ctx.getConfiguration();
LoggerConfig loggerConfig = config.getLoggerConfig(loggerName);
loggerConfig.setLevel(level);
ctx.updateLoggers();
Note that the LoggerConfig returned may not match loggerName - it might be a
parent. Also, adding a new LoggerConfig to an existing configuration is not
allowed as it cannot be done atomically. In that case you have to create a new
configuration.
Ralph
On Jul 22, 2013, at 2:04 PM, Nicholas Williams wrote:
> I can live with having to use the Core directly to change logger
> levels, as opposed to using the API. But your solution of cloning,
> changing, and replacing the configuration seems extremely heavy and
> excessive for merely changing the level for a single logger. There are
> a lot of other things that happen as a result that are completely
> unrelated to changing the level for a logger.
>
> Note that org.apache.log4j.Logger from Log4j 1 includes a setLevel
> method. While I understand that Log4j 1 isn't a separated
> API/implementation like Log4j 2, users are used to being able to
> easily change Logger levels, and you WILL (I'm confident) start seeing
> "Why is this so hard" questions when Log4j 1 sunsets and users start
> migrating en masse.
>
> On Mon, Jul 22, 2013 at 3:48 PM, Ralph Goers <[email protected]>
> wrote:
>> I guess I have to disagree. With Logback it is more explicit since SLF4J is
>> its API. The more of this stuff that gets added to the API the more
>> difficult it is going to be to keep the API separate from the
>> implementation. My view is that the API is primarily for applications that
>> want to use Log4j to generate Log events. Doing things to customize how
>> Appenders, Loggers, Filters, etc work is very much tied to the
>> implementation. Note that none of those are exposed in the API today and
>> you would have to to do what you are proposing.
>>
>> Ralph
>>
>> On Jul 22, 2013, at 12:56 PM, Gary Gregory wrote:
>>
>>> This seems like an "obvious" feature and should be part of the public
>>> API/feature set (IMO).
>>>
>>> Gary
>>>
>>>
>>> On Mon, Jul 22, 2013 at 3:08 PM, Nick Williams <
>>> [email protected]> wrote:
>>>
>>>> We do the _exact same thing_ in our apps that use Log4j 1. Being able to
>>>> do this is crucial to us. Being able to do this using the API is ideal and
>>>> obviously preferred so that the Core can be a runtime dependency, but as
>>>> long as we can do it one way or another we're ok.
>>>>
>>>> Nick
>>>>
>>>> On Jul 22, 2013, at 2:05 PM, Gary Gregory wrote:
>>>>
>>>>> Here is a user story I have at work all the time, which I'd like to be
>>>> able
>>>>> to do in Log4J 2 when we eventually migrate to it.
>>>>>
>>>>> Our server starts. A couple of days later, something goes wrong. Our user
>>>>> contacts us and we tell them to use our admin console to enable debugging
>>>>> for X and Y. This causes the log levels for certain loggers to be set to
>>>>> DEBUG, which spits out lots of details. The user then sends us the log
>>>> file
>>>>> and resets the system to normal. Under the covers the loggers go back to
>>>>> INFO or WARN.
>>>>>
>>>>> Our console sends a request to the server, which in turns uses the log4j
>>>> 1
>>>>> API to change the log level.
>>>>>
>>>>> How would I do that in v2?
>>>>>
>>>>> Gary
>>>>>
>>>>>
>>>>> On Mon, Jul 22, 2013 at 1:55 PM, Ralph Goers <[email protected]
>>>>> wrote:
>>>>>
>>>>>> Can you explain what it is you are really trying to do? Rather than
>>>> just
>>>>>> answer specific questions I am wondering if there isn't a better way to
>>>> do
>>>>>> what you want.
>>>>>>
>>>>>> Ralph
>>>>>>
>>>>>>
>>>>>> On Jul 22, 2013, at 7:14 AM, SMITH, CURTIS wrote:
>>>>>>
>>>>>>> From a thread back in May:
>>>>>>>
>>>>>>> My question to the below snips of the thread are;
>>>>>>>
>>>>>>> My app has many Catagories (using 1.x terminology). To setLevel in 1.x
>>>>>> I had to getCurrentCatagories() and iterate over the list setting level.
>>>>>>>
>>>>>>> In 2.x, does the code below set all Appenders regardless of what Level
>>>>>> they were set to in log4j.xml?
>>>>>>>
>>>>>>> loggerConfig.setLevel(Level.DEBUG);
>>>>>>> ctx.updateLoggers();
>>>>>>>
>>>>>>> The next question is how to set the level of just one Appender
>>>>>> (Logger??) ? Is there a way to get the list / iterator of
>>>>>> Appenders(Logger?) like you could get a a list of Catagories in 1.x?
>>>>>>>
>>>>>>> It appears that LogManager.getLogger("foo") you need to know the logger
>>>>>> names at coding time.
>>>>>>>
>>>>>>>
>>>>>>> Thanks, curt
>>>>>>>
>>>>>>> =======
>>>>>>>
>>>>>>> Ralph Goers said:
>>>>>>>>> No, the X Logger does not inherit its level from the root Logger. It
>>>>>> inherits its level from
>>>>>>> the root LoggerConfig. See the picture at
>>>>>> http://logging.apache.org/log4j/2.x/manual/architecture.html.
>>>>>>>
>>>>>>> The level you are modifying is brought into each Logger so that the
>>>>>> level can be tested very
>>>>>>> quickly. That is why the note on the setLevel method says it is
>>>>>> there primarily for unit
>>>>>>> testing.
>>>>>>>
>>>>>>> To do what you are attempting below you would need to do:
>>>>>>>
>>>>>>> LoggerContext ctx = (LoggerContext) LogManager.getContext(false);
>>>>>>> Configuration config = ctx.getConfiguration();
>>>>>>> LoggerConfig loggerConfig = config.getRootLogger();
>>>>>>> /* You could also specify the actual logger name as below and it
>>>>>> will return the LoggerConfig
>>>>>>> used by the Logger.
>>>>>>> LoggerConfig loggerConfig = getLoggerConfig("X");
>>>>>>> */
>>>>>>> loggerConfig.setLevel(Level.DEBUG);
>>>>>>> ctx.updateLoggers(); // This causes all Loggers to refetch
>>>>>> information from their LoggerConfig.
>>>>>>>
>>>>>>> Ralph
>>>>>>>
>>>>>>> Eric Scheie said:
>>>>>>>>> This
>>>>>>> is the actual code I used.
>>>>>>>
>>>>>>> LoggerContext ctx = (LoggerContext) LogManager.getContext(false);
>>>>>>>
>>>>>>> Configuration config = ctx.getConfiguration();
>>>>>>>
>>>>>>> LoggerConfig loggerConfig = config.getLoggerConfig(LogManager.
>>>>>>> ROOT_LOGGER_NAME);
>>>>>>>
>>>>>>> loggerConfig.setLevel(level);
>>>>>>>
>>>>>>> ctx.updateLoggers();
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> 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]
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> E-Mail: [email protected] | [email protected]
>>>>> Java Persistence with Hibernate, Second Edition<
>>>> http://www.manning.com/bauer3/>
>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>> Blog: http://garygregory.wordpress.com
>>>>> Home: http://garygregory.com/
>>>>> Tweet! http://twitter.com/GaryGregory
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>>
>>>>
>>>
>>>
>>> --
>>> E-Mail: [email protected] | [email protected]
>>> Java Persistence with Hibernate, Second
>>> Edition<http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>
>>
>> ---------------------------------------------------------------------
>> 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]
