I should add that the LoggerConfig and Configuration was one of the first
things I worked on when I started working on 2.0. Things have changed since
then so it might possible to add a new LoggerConfig to an existing
configuration. I'd have to review it and remind myself of what the problems
were.
Ralph
On Jul 22, 2013, at 2:59 PM, Ralph Goers wrote:
> 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 <ralph.go...@dslextreme.com>
>> 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 <
>>>> nicho...@nicholaswilliams.net> 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 <ralph.go...@dslextreme.com
>>>>>> 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: log4j-user-unsubscr...@logging.apache.org
>>>>>>>> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
>>>>>>> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>>>>>> 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: log4j-user-unsubscr...@logging.apache.org
>>>>> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>>>> 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: log4j-user-unsubscr...@logging.apache.org
>>> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
>> For additional commands, e-mail: log4j-user-h...@logging.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org
