[
https://issues.apache.org/jira/browse/LOG4J2-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13961593#comment-13961593
]
Bruce Brouwer commented on LOG4J2-585:
--------------------------------------
* Well, my recommendation in using define is that it would actually change the
parent hierarchy to be what is listed, so it is different than the current
.getMarker(...). This way if I wasn't careful in my code, I wouldn't have to
worry about the order of calls between .getMarker(name) and .define(name,
parents...) (think if my markers are static member variables and I have little
control over the order of class initialization). If getMarker(name) did somehow
get called before define(name, parents...) they would both be pointing at the
same marker and with the parent heirarchy I desired. I just now need to make
sure that I only call define(name, parents...) once for each marker name.
* Cool, thanks
* I'm not talking about a cycle. I agree we need to avoid cycles. given A -> B
-> C (A is child, B is parent, C is grand parent). If I add C to A, there is no
cycle, it just is doubly parented on C. The cycle would happen if I tried to
add A as a parent of C. The check {{parent.isInstanceOf(this)}} is completely
valid and is what checks for the cycle. The check {{this.isInstanceOf(parent)}}
is what I'm asking to change to only check immediate parents.
* Cool, thanks
* When I implemented this in my concept, I simply had the marker reference be
null until it was attached. Once I add that detached marker to another attached
marker, my reference to the detached marker should be considered invalid. Any
use of it with the contains method against an attached marker should return
false, even if there was an attached marker with the same name that was
contained by the attached marker. When the marker is attached, I'm not asking
to stop using the == check, I think that part is perfect. But I do understand
that this makes the add method considerably more complicated, partly because it
would need to check for cycles by checking parent names instead of ==, and
partly because I might be attaching an entire parent hierarchy, not just a
single marker. (I'm sure I'm just securing in your mind that it isn't worth it,
aren't I?)
> Markers not as powerful as slf4j
> --------------------------------
>
> Key: LOG4J2-585
> URL: https://issues.apache.org/jira/browse/LOG4J2-585
> Project: Log4j 2
> Issue Type: Improvement
> Components: API
> Affects Versions: 2.0-rc1
> Reporter: Bruce Brouwer
> Attachments: ConceptMarkerBenchmark.java,
> CurrentMarkerBenchmark.java, log4j2-585-concept.patch
>
>
> Log4J's markers are not as flexible as markers in SLF4J.
> First, SLF4J's markers are mutable. By allowing markers to be mutable, I can
> change the relationship of markers to each other based upon runtime or
> business conditions.
> Second, and more importantly I think, is that essentially SLF4J markers have
> this parent/child relationship, much like Log4J, except that in SLF4J, I can
> essentially have a marker with multiple parents. For example, I might want
> this structure:
> * Animal
> ** Bird
> *** Duck
> ** Mammal
> *** Bear
> *** Dolphin
> * Travels by
> ** Water
> *** Duck
> *** Dolphin
> ** Land
> *** Duck
> *** Bear
> ** Air
> *** Duck
> Of course, this is a contrived example, but I wanted to describe the
> relationships. Now, if I wanted to filter based on markers that travel by
> Water for some appenders, and another appender wants to filter by Mammals, I
> can't simply use the single marker of Dolphin.
> Either we need to reverse the marker relationship so that it contains its
> children, much like SLF4J, or we allow markers to have multiple parents,
> which I prefer because it could make it more succinct to define:
> {code}
> private static final Marker BY_LAND = MarkerManager.getMarker("BY_LAND");
> private static final Marker BY_WATER = MarkerManager.getMarker("BY_WATER");
> private static final Marker DUCK = MarkerManager.getMarker("DUCK", BY_LAND,
> BY_WATER);
> {code}
> As for the Marker API, we would either need to change getParent to
> getParents, or get rid of the getParent method from the API and just rely on
> the isInstanceOf method to handle checking multiple parents by looking at
> private member variables (my preference)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
