And if you can Javadoc things as you recall them, that much the better! :)
Gary
On Jul 23, 2013, at 11:23, Ralph Goers <ralph.go...@dslextreme.com> wrote:
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org
