[
https://issues.apache.org/jira/browse/LOG4J2-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13961566#comment-13961566
]
Bruce Brouwer commented on LOG4J2-585:
--------------------------------------
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?
* slf4j-impl Log4jMarker is still backwards, treating parents as children and
children as parents. My concept code showed how I took care of this. In most
cases, there is no real performance penalty.
* 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: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
