[
https://issues.apache.org/jira/browse/LOG4J2-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13954805#comment-13954805
]
Bruce Brouwer edited comment on LOG4J2-585 at 3/30/14 7:12 PM:
---------------------------------------------------------------
Cool. So, in my patch, when I make log4j Markers mutable, I will make sure read
operations are as performant as possible, but for operations that modify
markers, I am not going to spend a lot of effort making those highly performant
as I think read operations are far more important.
Of the items in the concurrent collections, the one that seemed promising to me
for this situation was ConcurrentHashMap, but it does not maintain the original
order and I don't really need the Map feature, just Set. The only place where I
think order might have some impact when allowing multiple parents is in the
toString method. It wouldn't keep the order that was specified when creating
the marker with parents. Do you think order is important in the toString
method? Could I get away with just sorting the parent names for .toString()? If
so, then I can seriously consider ConcurrentHashMap. Otherwise I'll have to go
with another collection and use the ReentrantReadWriteLock.
was (Author: bruce.brouwer):
Cool. So, in my patch, when I make log4j Markers mutable, I will make sure read
operations are as performant as possible, but for operations that modify
markers, I am not going to spend a lot of effort making those highly performant
as I think read operations are for more important.
Of the items in the concurrent collections, the one that seemed promising to me
for this situation was ConcurrentHashMap, but it does not maintain the original
order. The only place where I think order might have some impact when allowing
multiple parents is in the toString method. It wouldn't keep the order that was
specified when creating the marker with parents. Do you think order is
important in the toString method? Could I get away with just sorting the parent
names for .toString()? If so, then I can seriously consider ConcurrentHashMap.
Otherwise I'll have to go with another collection and use the
ReentrantReadWriteLock.
> 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]
