This use case makes perfect sense to me. Ralph
> On Aug 22, 2015, at 10:29 AM, Xen <x...@dds.nl> wrote: > > Personally I believe the use case of setting a parent (beginning point) and > all its descendents to a certain level is a bit odd. > > As it seems there are basically two important reasons to have different > LoggerConfigs for children: > > 1) to have different levels > 2) to have different appenders. > > Of course it means you can turn an entire subsystem to e.g. debug. > > So the only real case would seem to be that you don't want different levels, > but still want different appenders. If you didn't care about levels and > appenders at all (supposedly) you wouldn't create new loggerconfigs. > > So now you have parts of a subsystem logging perhaps to another database > because you want to study lowlevel dynamics or whatever. Maybe you are > interested in obtaining metrics of a certain subsystem. But now for some > reason you want the entire system (or subsystem of which that other subsystem > is a part) to become homogenous and output all at the same level. > > That seems to me to fly in the face of creating distinct and separate > loggerconfigs in the first place. Because, how are you going to reset it to > its original state?. I forgot the term -- additivity, I could only remember > it as 'inheritance'. You might imagine some descendent logger not inheriting > from its ancestor. Having a different appender or otherwise config. > > What will you do after you've all set them to the same level?. If that was > your intent all along, why not create them with that level?. Or is the idea > to keep raising and lowering the entire tree based on conditions or > customer/user input?. Then basically what you want is for the levels to be > linked, I guess that could happen. > > So I really don't know. It just still seems odd. > > Regards, B. > > > > On Sat, 22 Aug 2015, Gary Gregory 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 <ralph.go...@dslextreme.com> >> 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 <garydgreg...@gmail.com> wrote: >>> >>> On Wed, Aug 19, 2015 at 7:59 PM, Gary Gregory <garydgreg...@gmail.com> >>> wrote: >>> >>>> On Sat, Aug 15, 2015 at 3:56 PM, Gary Gregory <garydgreg...@gmail.com> >>>> wrote: >>>> >>>>> On Sat, Aug 15, 2015 at 3:07 PM, Ralph Goers <ralph.go...@dslextreme.com >>>>>> 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 <garydgreg...@gmail.com> >>>>>> 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: garydgreg...@gmail.com | ggreg...@apache.org >>>>>> <ggreg...@apache.org <mailto:ggreg...@apache.org>> >>>>>> Java Persistence with Hibernate, Second Edition >>>>>> <http://www.manning.com/bauer3/ <http://www.manning.com/bauer3/>> >>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/ >>>>>> <http://www.manning.com/tahchiev/>> >>>>>> Spring Batch in Action <http://www.manning.com/templier/ >>>>>> <http://www.manning.com/templier/>> >>>>>> Blog: http://garygregory.wordpress.com >>>>>> <http://garygregory.wordpress.com/> >>>>>> Home: http://garygregory.com/ <http://garygregory.com/> >>>>>> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> E-Mail: garydgreg...@gmail.com <mailto:garydgreg...@gmail.com> | >>>>> ggreg...@apache.org <mailto:ggreg...@apache.org> >>>>> <ggreg...@apache.org <mailto:ggreg...@apache.org>> >>>>> Java Persistence with Hibernate, Second Edition >>>>> <http://www.manning.com/bauer3/ <http://www.manning.com/bauer3/>> >>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/ >>>>> <http://www.manning.com/tahchiev/>> >>>>> Spring Batch in Action <http://www.manning.com/templier/ >>>>> <http://www.manning.com/templier/>> >>>>> Blog: http://garygregory.wordpress.com <http://garygregory.wordpress.com/> >>>>> Home: http://garygregory.com/ <http://garygregory.com/> >>>>> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory> >>>>> >>>> >>>> >>>> >>>> -- >>>> E-Mail: garydgreg...@gmail.com <mailto:garydgreg...@gmail.com> | >>>> ggreg...@apache.org <mailto:ggreg...@apache.org> >>>> <ggreg...@apache.org <mailto:ggreg...@apache.org>> >>>> Java Persistence with Hibernate, Second Edition >>>> <http://www.manning.com/bauer3/ <http://www.manning.com/bauer3/>> >>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/ >>>> <http://www.manning.com/tahchiev/>> >>>> Spring Batch in Action <http://www.manning.com/templier/ >>>> <http://www.manning.com/templier/>> >>>> Blog: http://garygregory.wordpress.com <http://garygregory.wordpress.com/> >>>> Home: http://garygregory.com/ <http://garygregory.com/> >>>> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory> >>>> >>> >>> >>> >>> -- >>> E-Mail: garydgreg...@gmail.com <mailto:garydgreg...@gmail.com> | >>> ggreg...@apache.org <mailto:ggreg...@apache.org> >>> <ggreg...@apache.org <mailto:ggreg...@apache.org>> >>> Java Persistence with Hibernate, Second Edition >>> <http://www.manning.com/bauer3/ <http://www.manning.com/bauer3/>> >>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/ >>> <http://www.manning.com/tahchiev/>> >>> Spring Batch in Action <http://www.manning.com/templier/ >>> <http://www.manning.com/templier/>> >>> Blog: http://garygregory.wordpress.com <http://garygregory.wordpress.com/> >>> Home: http://garygregory.com/ <http://garygregory.com/> >>> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory> >>> >>> >>> >> >> >> -- >> E-Mail: garydgreg...@gmail.com <mailto:garydgreg...@gmail.com> | >> ggreg...@apache.org <mailto:ggreg...@apache.org> >> Java Persistence with Hibernate, Second Edition >> <http://www.manning.com/bauer3/ <http://www.manning.com/bauer3/>> >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/ >> <http://www.manning.com/tahchiev/>> >> Spring Batch in Action <http://www.manning.com/templier/ >> <http://www.manning.com/templier/>> >> Blog: http://garygregory.wordpress.com <http://garygregory.wordpress.com/> >> Home: http://garygregory.com/ <http://garygregory.com/> >> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org > <mailto:log4j-dev-unsubscr...@logging.apache.org> > For additional commands, e-mail: log4j-dev-h...@logging.apache.org > <mailto:log4j-dev-h...@logging.apache.org>
