[
https://issues.apache.org/jira/browse/LOG4J2-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13961566#comment-13961566
]
Bruce Brouwer edited comment on LOG4J2-585 at 4/6/14 11:45 PM:
---------------------------------------------------------------
So, here are my thoughts. Maybe some of these should be made into new JIRAs.
* Are we ok with getMarker sometimes creating a marker with the specified
parents and sometimes returning a marker with a potentially different parent
hierarchy? This is why my concept renamed those methods to define(name,
parents...).
* Do we want a version of getMarker (or define) that takes a list of parent
marker names, in addition to the new one that takes a list of marker instances?
* Should it be ok to add a parent twice in the hierarchy, once as a grand
parent, once as a parent? If I was allowed to add marker X as an immediate
parent of Y when X already existed as a grandparent, then removing the X
grandparent would allow marker Y to remain an instance of X. The current
implementation would not allow me to add X as a parent of Y and thus removing
grandparent X would make Y no longer an instance of X, even though I explicitly
specified I wanted X to be an immediate parent of Y. (This one is pretty minor
and I'm willing to accept what is done)
* Log4jMarker.getParents() should return a copy of the array so I can't change
the contents from outside the control of log4j
* Would a switch statement in Log4jMarker.isInstanceOf provide better
performance, so there aren't multiple length checks?
* In slf4j-impl Log4jMarkerFactory.getDetachedMarker(), my impression was that
it should create a marker that wasn't actually attached yet to log4j, but by
adding it to another attached marker would then make it attached. This
implementation essentially creates the slf4j marker as already attached.
was (Author: bruce.brouwer):
So, here are my thoughts. Maybe some of these should be made into new JIRAs.
* Are we ok with getMarker sometimes creating a marker with the specified
parents and sometimes returning a marker with a potentially different parent
hierarchy? This is why my concept renamed those methods to define(name,
parents...).
* Do we want a version of getMarker (or define) that takes a list of parent
marker names, in addition to the new one that takes a list of marker instances?
* Should it be ok to add a parent twice in the hierarchy, once as a grand
parent, once as a parent? If I was allowed to add marker X as an immediate
parent of Y when X already existed as a grandparent, then removing the X
grandparent would allow marker Y to remain an instance of X. The current
implementation would not allow me to add X as a parent of Y and thus removing
grandparent X would make Y no longer an instance of X, even though I explicitly
specified I wanted X to be an immediate parent of Y. (This one is pretty minor
and I'm willing to accept what is done)
* Log4jMarker.getParents() should return a copy of the array so I can't change
the contents from outside the control of log4j
* Would a switch statement in Log4jMarker.isInstanceOf provide better
performance, so there aren't multiple length checks?
* In slf4j-impl Log4jMarkerFactory.getDetachedMarker(), my impression was that
it should create a marker that wasn't actually attached yet to log4j, but by
adding it as a child to a parent that is attached would then make it attached.
This implementation essentially creates the slf4j marker as already attached.
> 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]
