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
