logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: Log4j2: Programmatically setting log4j2 log level
Date Wed, 24 Jul 2013 16:22:55 GMT
On Mon, Jul 22, 2013 at 5:59 PM, Ralph Goers <ralph.goers@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


> 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.goers@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 <
> >>> nicholas@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.goers@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-unsubscribe@logging.apache.org
> >>>>>>> For additional commands, e-mail:
> log4j-user-help@logging.apache.org
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> >>>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@logging.apache.org
> >>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> E-Mail: garydgregory@gmail.com | ggregory@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-unsubscribe@logging.apache.org
> >> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-user-help@logging.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message