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. 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.
>
I've thought about this a little now and it seems that, yes, this is an
infrequent operation (logger.setLevel() or someClass.setLevel(Logger,
Level)) in the sense that there will not be many call sites in an
application, in fact, you only really need one such call site, I claim, in
any application. BUT, I also claim that any long running application, like
a server, will _require_ this as a feature.
So it does not matter how ofter this feature is used, it just needs to be
there, somewhere.
I propose we at least start by adding a method somewhere in Core that is
the official Core-way of setting the log level for a running application.
This will give us an API to call, tied to Core, but better that writing the
kind of Log4J gut code outline above is applications.
Whether or not this need to be in the API module can be left as a separate
discussion.
Gary
> 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
