logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bruce Brouwer (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (LOG4J2-585) Markers not as powerful as slf4j
Date Thu, 03 Apr 2014 21:05:19 GMT

    [ https://issues.apache.org/jira/browse/LOG4J2-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13959213#comment-13959213
] 

Bruce Brouwer edited comment on LOG4J2-585 at 4/3/14 9:04 PM:
--------------------------------------------------------------

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 extends Marker { }
public interface MySecondParentMarker extends Marker { }
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? The best idea I can come up with here is to change the log4j-api
to take a {{Class<? extends Marker> marker}} instead of {{Marker marker}}. Now there
is no need for a MarkerManager as the Java class loader takes care of it for me. 

I like this idea, except that I don't see a way to make it work with slf4j. 


was (Author: bruce.brouwer):
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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Mime
View raw message