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

Reply via email to