[
https://issues.apache.org/jira/browse/LOG4J2-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13954878#comment-13954878
]
Bruce Brouwer commented on LOG4J2-585:
--------------------------------------
Interesting. I don't know if it makes sense for each logger to have a marker
factory, but in the way we have different LoggerContextFactory implementations,
we could have different MarkerFactory implementations. log4j-slf4j-impl could
provide an alternate MarkerFactory. I don't know if I like the idea of simply
including log4j-slf4j-impl and having it switch the implementation of
MarkerFactory without me realizing it. But I suppose that is what happens when
I include log4j-core with LoggerContextFactory. It seems different to me,
somehow. I would expect log4j-slf4j-impl to be a thin wrapper around the real
log4j implementation, including the markers.
I was actually thinking a bit about the Marker interface. If we don't go with
the MarkerFactory idea, what is the point of having Marker be an interface? It
should be a concrete final class to prevent anyone or anything making other
kinds of Markers. I could see weird things happening if we pass an SLF4J marker
with one hierarchy passed into a Log4J marker's .isInstanceOf method. We could
run into a situation where slf4jMarker.isInstanceOf(log4jMarker) returns true
and also log4jMarker.isInstanceOf(slf4jMarker) returns true, event though they
are not themselves equal. This doesn't really make good logical sense. The only
impact I think would be that the log4j-slf4j-impl MarkerWrapper couldn't
implement Marker, but would rather need to provide a getter.
I'm willing to put in some time developing this, even at the risk of not using
it if it proves to be too big of a performance hit. But if we don't go down
this road, we run into the problem of the SLF4J marker hierarchy possibly being
inconsistent with the Log4j marker hierarchy and having some of the weird
behavior I described.
> 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
>
> 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]
