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