On Thu, 27 Aug 2015, Gary Gregory wrote:
setDescendentTreeLevels ;-).
Hm... but 'descendant' means the same as 'children' to me. I am not my own
descendant so that word is just as 'wrong' as children.
The word 'tree' does convey that we are not just looking at the immediate
decendants/children. I like 'tree' better than 'branch'.
setTreeLevel(String, Level)?
Nice discussion :-)
Gary
Yes it's interesting, what do you call a branch? A branch! :P.
I mean a tree has a root. Every tree, or subtree, always has a root, you
typically design around that when making trees. The children of a root
node can be many, so children is plural, but the branch (or subtree) is
singular. I called it "descendent-tree" as a form of "subtree". You have a
hierarchy, whether you like it or not. In normal, compositing tree
construction any and every node is a tree of its own. You take a node,
it's a tree. The node might then have a method like "do all of this to the
entire tree". You could say TreeTraverser tt;
tt.findNode("server").applyToAll(method) or .setAllLevels(level) -- but
then you wouldn't have a static method.
The TreeTraverser might have a static method .setAllLevels and then you
get into the issue we have now. You would then probably call it
setSubtreeLevels or something. Or it'd be a kind of lambda; you just have
a method for traversing an entire subtree (iterating, enumerating) and
applying a certain function or transformation to it (which might also
result in a copy of the subtree, much like the array_map functionality of
PHP.
From the viewpoint of an encapsulating class, that takes "name, level" or
"name, method" or "name, parameter, value" it would still have to be
something (generic, as we speak) like "setDecendentTreeLevel" or
setDecendentTreeParam, or setSubTree or setSubTreeParam or whatever.
The problem is the wrapper class itself, because it implies a single root.
I don't think there is really an elegant naming solution for that. But the
only thing that identifies a subtree is "branch" or "subtree" or perhaps
strangely "descendentTree" but only because it is less generic really ;-).
Of course you are trying to find a term that coincides with Log4j. But all
the same:
there is in mathematics also the concept of 'subtree' that is inclusive
and 'subtree' that is exclusive. For example, there is "subset" but subset
might indicate complete equality of the set to its superset. To
distinguish between "subset" and a subset that actually is smaller than
the parent set, the term "proper subset" is used. So you would call it a
"proper subtree". Subset by itself does not actually imply immediately
that the set is smaller, and subtree by itself does not imply that the
parent node is excluded (of course, it couldn't even be in a tree, unless
you take one of the children and use it as the subtree). And because
"DescendentTree" is in that sense equivalent to "Sub-Tree" it also does
not have to be exclusive. In other words.:
If the tree is
A
\-- B -- C
\-- D
Then A is a subtree of A, but B is a proper subtree of A.
However, when you no longer talk of subtrees but rather of children, it
would be that A is naturally not a child of A, that is why I thought
"decendent-tree" (singular) is different from "children" (plural).
Nevertheless, because even the root tree is a subtree of the root tree
(but not a proper subtree) I think you should include the nomenclature of
"sub" or "branch" somewhere in the name, even if you call it "descendent"
or "below" or anything.
If you wanted to call "setTreeLevels" on a LoggerConfig itself; that is
probably something that would find my attention rather than an accessor
method on a static class (or even nonstatic). (I mean static method). I
would simply do:
Context.getConfiguration().getLoggerConfig("name").setAllChildrenToLevel(level)
and I would not care about the name.
or I would do
Context.getConfigurator().setChildrenLevelsTo("name", level)
and I would not care about the name.
And I would simply feel that, hey, let's just be a child of yourself ;-).
In my own tree implementation (research, that I do in PHP) I believe I
have even done away with the concept of children, you have a parent, but
you don't have children, you only have nodes, and the first node you have
is a reference to your self. The name each node has for you is not the
name of the node, it is your reference to the node, that belongs to you,
not to the node. GetChildren() is then a convenience method that returns
the "proper subtree" instead of the default tree, I guess. It excludes the
self node. I like the idea of having a path to your Self ;-). I'm not sure
what the power is yet. Every node is a Tree, and there is (like I
indicated) a TreeTraverser that provides exploration methods. A
TreeTraverser is like someone who walks across the tree, that travels the
tree and does things to it or with it.
But the fact is that currently Configurator is a rather static, absolute
class, you have no direct path to it, or rather, only a direct path?. It
is weird that you have all these classes and you can refer them from
anywhere. There are too many entrances. It is like a building with 5
different desks but not a single reception desk. That is why I feel that,
as part of the current Configurator,
even though the solution is therefore suboptimal, you have to make
something that coincides with what it is....
And that is why I would say Configurator.setDescendentTreeLevels() would
be the best solution.
I think that, within that context, within that /given/ context, that that
would be the most clear name that would enable a user to understand what
it does.
Anyway, that is My rationale, I guess.
All of the other names I've given are within their respective contexts, or
rather, their /proper/ contexts ;-).
Regards, and kudos, and smiles ;-).
Bart.
Quoting Gary Gregory <garydgreg...@gmail.com>:
Ah! Tricky stuff, that typing ;-)
Committed.
Gary
On Thu, Aug 27, 2015 at 12:44 PM, Ralph Goers <ralph.go...@dslextreme.com
wrote:
No. Autocorrect at work. Should have been ?Sounds?
Ralph
On Aug 27, 2015, at 12:24 PM, Gary Gregory <garydgreg...@gmail.com>
wrote:
Pardon my lack of urban engagement ;-) but do you mean "Spuds" as in
http://www.urbandictionary.com/define.php?term=Spud+Me
Gary
On Thu, Aug 27, 2015 at 12:07 PM, Ralph Goers <
ralph.go...@dslextreme.com>
wrote:
Spuds ok to me
Sent from my iPad
On Aug 27, 2015, at 11:49 AM, Gary Gregory <garydgreg...@gmail.com>
wrote:
setAllChildLevels is nice and explicit, but like setChildren it does not
convey the fact that the API sets the _given_ level _and_ its children.
Maybe setAllLevels(String, Level) ?
Gary
On Thu, Aug 27, 2015 at 11:24 AM, Ralph Goers <
ralph.go...@dslextreme.com
wrote:
setBranch doesn?t resonate with me. Partly the problem is that you
don?t identify what is being set in the name. I would actually prefer
something like setAllChildLevels.
Ralph
On Aug 27, 2015, at 11:17 AM, Gary Gregory <garydgreg...@gmail.com>
wrote:
Ohhh, I like setBranch instead of setChildren. I'll let it simmer for a
little...
Thoughts from others?
Gary
On Thu, Aug 27, 2015 at 7:15 AM, Xen <x...@dds.nl> wrote:
Maybe you can call it setBranch() instead, since you are really trying
to set an entire branch of a tree, and you are no so much worried
about the
fact that they are children. In other words, the parent is included
too.
On Wed, 26 Aug 2015, Gary Gregory wrote:
On Sat, Aug 22, 2015 at 1:58 PM, Gary Gregory <garydgreg...@gmail.com
wrote:
In this case the caller is setChildren, so it would know. I've not
experimented with coding this yet though.
A reminder that this new code has been in for a couple of days and
that I
am not in love with the API name setChildren, so I am open to
suggestions.
Gary
Gary
On Sat, Aug 22, 2015 at 11:10 AM, Ralph Goers <
ralph.go...@dslextreme.com>
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 <garydgreg...@gmail.com>
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 <
garydgreg...@gmail.com>
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 <
garydgreg...@gmail.com>
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>
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
<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
<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
<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
--
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
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-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
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-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-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
