In this case the caller is setChildren, so it would know. I've not
experimented with coding this yet though.

Gary

On Sat, Aug 22, 2015 at 11:10 AM, Ralph Goers <[email protected]>
wrote:

> Yes. Except that puts the burden on the caller to keep track of everything
> they modified.
>
> Ralph
>
> On Aug 22, 2015, at 9:33 AM, Gary Gregory <[email protected]> wrote:
>
> Furthermore could loggerContext.updateLoggers() be optimized by passing
> it the the list of LoggerConfigs we modifed?
>
> Gary
>
> On Sat, Aug 22, 2015 at 9:04 AM, Gary Gregory <[email protected]>
> wrote:
>
>> Ah, like this then?
>>
>>     /**
>>      * Sets the levels of <code>parentLogger</code> and all 'child'
>> loggers to the given <code>level</level>.
>>      * @param parentLogger the parent logger
>>      * @param level the new level
>>      */
>>     public static void setChildren(final String parentLogger, final Level
>> level) {
>>         // get logger config
>>         // if exact match? Use it, if not, create it.
>>         // set level
>>         // update loggers
>>         final LoggerContext loggerContext =
>> LoggerContext.getContext(false);
>>         final Configuration config = loggerContext.getConfiguration();
>>         boolean set = setLevel(parentLogger, level, config);
>>         final Map<String, LoggerConfig> loggerConfigMap =
>> config.getLoggers();
>>         for (Map.Entry<String, LoggerConfig> entry :
>> loggerConfigMap.entrySet()) {
>>             if (entry.getKey().startsWith(parentLogger)) {
>>                 set |= setLevel(entry.getValue(), level);
>>             }
>>         }
>>         if (set) {
>>             loggerContext.updateLoggers();
>>         }
>>     }
>>
>> Gary
>>
>> On Sat, Aug 22, 2015 at 8:19 AM, Gary Gregory <[email protected]>
>> wrote:
>>
>>> Let's say I have
>>>
>>> Logger com = ERROR (or even just the root Logger at ERROR).
>>>
>>> and I want Logger com.domain.foo and all its children set to DEBUG
>>>
>>> If I get the LoggerConfig that matches the parent logger and call
>>> setLevel on that, I will end up with Logger com at DEBUG, won't I?
>>>
>>> Gary
>>>
>>> On Fri, Aug 21, 2015 at 9:53 PM, Ralph Goers <[email protected]
>>> > wrote:
>>>
>>>> That is definitely not how to implement it.
>>>>
>>>> You should get the LoggerConfig that matches your parent logger and
>>>> call setLevel on that. Then loop through all the loggerConfigs that start
>>>> with the located LoggerConfigs name and then call setLevel on them.  You
>>>> typically aren’t going to have many LoggerConfigs while you could have
>>>> thousands of Loggers, which all resolve to the same LoggerConfig.
>>>>
>>>> Ralph
>>>>
>>>> On Aug 21, 2015, at 9:30 PM, Gary Gregory <[email protected]>
>>>> wrote:
>>>>
>>>> On Wed, Aug 19, 2015 at 7:59 PM, Gary Gregory <[email protected]>
>>>> wrote:
>>>>
>>>>> On Sat, Aug 15, 2015 at 3:56 PM, Gary Gregory <[email protected]>
>>>>>  wrote:
>>>>>
>>>>>> On Sat, Aug 15, 2015 at 3:07 PM, Ralph Goers <
>>>>>> [email protected]> wrote:
>>>>>>
>>>>>>> Why do you want to set the level on the LoggerConfig and all its
>>>>>>> descendants?
>>>>>>>
>>>>>>
>>>>>> Because I clearly did not educate myself fully in this topic. ;-)
>>>>>> Hence I am looking for a shortcut by asking on the ML :-)
>>>>>>
>>>>>>
>>>>>>> Setting the level just on the LoggerConfig will achieve the same
>>>>>>> thing, so long as none of its descendants has a LoggerConfig
>>>>>>>
>>>>>>
>>>>>> That's cool, but... How can I know if any descendant has a
>>>>>> LoggerConfig? How can do this generically?
>>>>>>
>>>>>
>>>>> Here is my proposal (including a test):
>>>>> https://issues.apache.org/jira/secure/attachment/12751400/log4j.diff
>>>>>
>>>>> I am not crazy about the API name: setChildren(String loggerName,
>>>>> Level level).
>>>>>
>>>>> Thoughts?
>>>>>
>>>>
>>>> Anyone? Bueller? :-)
>>>>
>>>>
>>>>>
>>>>> Gary
>>>>>
>>>>>
>>>>>> Gary
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Sent from my iPad
>>>>>>>
>>>>>>> On Aug 15, 2015, at 8:25 AM, Gary Gregory <[email protected]>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Let's say I have a logger tree like:
>>>>>>>
>>>>>>> R
>>>>>>> R.P
>>>>>>> R.P.C1
>>>>>>> R.P.C1.L1
>>>>>>> R.P.C2.L2
>>>>>>> R.P.C2
>>>>>>> R.P.C2.L1
>>>>>>> R.P.C2.L2
>>>>>>>
>>>>>>> and I want to set R.P.C2 and all it's descendants to a given level.
>>>>>>>
>>>>>>> In Log4j 1.2, I do:
>>>>>>>
>>>>>>>     public static void setChildren(final Logger parentLogger, final
>>>>>>> Level newLevel) {
>>>>>>>         final Enumeration<Logger> enumeration =
>>>>>>> LogManager.getCurrentLoggers();
>>>>>>>         while (enumeration.hasMoreElements()) {
>>>>>>>             final Logger logger = enumeration.nextElement();
>>>>>>>             if (LoggerUtils.isChild(parentLogger, logger)) {
>>>>>>>                 logger.setLevel(newLevel);
>>>>>>>             }
>>>>>>>         }
>>>>>>>     }
>>>>>>>
>>>>>>>     private static boolean isChild(final Logger parentCandidate,
>>>>>>> final Logger childCandidate) {
>>>>>>>         for (Category c = childCandidate; c != null; c =
>>>>>>> c.getParent()) {
>>>>>>>             if (c.equals(parentCandidate)) {
>>>>>>>                 return true;
>>>>>>>             }
>>>>>>>         }
>>>>>>>         return false;
>>>>>>>     }
>>>>>>>
>>>>>>> I suppose I could determine parent/child with a startWith on the
>>>>>>> logger name too.
>>>>>>>
>>>>>>> I there a better way to do this with the Core in v2 aside from
>>>>>>> iterating over all loggers in a context and doing a kind of isChild()? 
>>>>>>> Can
>>>>>>> additivity be used for this?
>>>>>>>
>>>>>>> I'd like to add such a utility method to Configurator.
>>>>>>>
>>>>>>> Gary
>>>>>>>
>>>>>>> --
>>>>>>> E-Mail: [email protected] | [email protected]
>>>>>>> <[email protected]>
>>>>>>> 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: [email protected] | [email protected]
>>>>>> <[email protected]>
>>>>>> 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: [email protected] | [email protected]
>>>>> <[email protected]>
>>>>> 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: [email protected] | [email protected]
>>>> <[email protected]>
>>>> 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: [email protected] | [email protected]
>>> 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: [email protected] | [email protected]
>> 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: [email protected] | [email protected]
> 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: [email protected] | [email protected]
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