[
https://issues.apache.org/jira/browse/LOG4J2-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13959213#comment-13959213
]
Bruce Brouwer commented on LOG4J2-585:
--------------------------------------
The problem with creating all new immutable markers is that there are likely to
be references to the old markers all throughout the code that are now invalid.
Now, I suppose I have opened up that possibility now by allowing markers to be
undefined and then redefined, but I think that is an even more rare case that
we don't need to be concerned with.
The other idea is something that I hadn't considered of before. I'm assuming
you mean marker "x.y.z" would have a parent of "x.y", which has a parent of
"x". However, this fails to give the ability to have multiple parents
If we went a completely different route and just had markers be interfaces, I
could see code like this:
{code}
public interface MyFirstParentMarker { }
public interface MySecondParentMarker { }
public interface MyChildMarker extends MyFirstParentMarker,
MySecondParentMarker { }
{code}
This has a few problems, too. First, I have no idea how we could get it to work
with slf4j which is based upon marker names being strings, not a Java type
hierarchy. Second, how do we reference these markers? Would we do it like this:
{code}
private final static Class<MyChildMarker> myChildMarker = MyChildMarker.class;
{code}
Or would we do something with Java proxies:
{code}
private final static MyChildMarker myChildMarker =
MarkerManager.get(MyChildMarker.class);
public class MarkerManager {
public static <T> T get(Class<T> markerType) {
return java.lang.reflect.Proxy.proxyClass(markerType);
}
}
{code}
I like this idea, except that I don't see a way to make it work with slf4j.
> 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
