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 <[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
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
