On Wed, Jul 24, 2013 at 12:22 PM, Gary Gregory <garydgreg...@gmail.com>wrote:
> On Mon, Jul 22, 2013 at 5:59 PM, Ralph Goers > <ralph.go...@dslextreme.com>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. > > > Wait a sec. So I f have two loggers "A.X" and "A.Y" and I call > config.getLoggerConfig("A.X") I might return "A" and I will end up setting > the log level for both "A.X" AND "A.Y"? > > That's not what anyone will want, at least not me. Did I misunderstand you? > > The question then is, how do I use the Core API to set the log level for a > specific logger. > > Gary > ping? Gary > > >> 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 >> >> > > > -- > 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 > -- 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