[
https://issues.apache.org/jira/browse/LOG4J2-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13960867#comment-13960867
]
Bruce Brouwer commented on LOG4J2-585:
--------------------------------------
So another idea I had is along the lines of what Gary was proposing. So we have
MarkerManager today, which is analogous to LogManager. But instead of
MarkerManager holding onto a static map of markers, what if the LoggerContext
is what actually kept track of all the markers, like it keeps track of all the
Loggers.
And like LoggerContext now returns LoggerProviders, LoggerContext could return
MarkerProviders, while the MarkerManager static methods would return simple
Markers. This would allow the public Marker API to be simpler than the Marker
SPI. The Marker SPI could have the methods that make markers mutable. The only
thing I can think that the API would be missing that the SPI has would be the
{{getParents}} method.
With this approach, there could be two LoggerContexts, each with their own
marker hierarchy, rather than one set of markers that everything shares.
Does this approach sound more palatable? I don't think it would be too hard to
switch my concept over to this approach.
Also, are the issues I've identified recognized as real issues? (e.g.
slf4j-impl markers having almost no relation to log4j markers) If the rest of
the team doesn't agree with me, I'll stop spending time on this. I will be
using log4j 2 primarily through the slf4j interface and I personally see this
as a real problem that needs to be fixed before 2.0.
> 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: 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
