logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Brouwer <bruce.brou...@gmail.com>
Subject Re: Proposed change to MarkerManager API
Date Mon, 07 Apr 2014 11:46:10 GMT
I would be happy with a solution that looked like this:

private static final Marker m =
MarkerManager.getMarker("m").setParents("p");

Where setParents is fluent by simply returning "this". Other names would be
possible: .parents(...), .withParents(...). I really dislike the slf4j
method where I have to setup parent relationships somewhere else, such as
in a static initializer block.

I'm not keen at all on changing the way marker hierarchies work to be
something like com.foo.MyMarker1. In that regard, I like the current
solution best.


On Mon, Apr 7, 2014 at 7:19 AM, Gary Gregory <garydgregory@gmail.com> wrote:

> On Mon, Apr 7, 2014 at 3:04 AM, Ralph Goers <ralph.goers@dslextreme.com>wrote:
>
>> Gary,  Markers are not Loggers. People don't use them to represent Java
>> classes but to represent states, categories or extensions to logging
>> levels.  Would you prefer that the logging levels be "
>> org.apache.logging.log4j.INFO" instead of just INFO?  In addition,
>> having to specify the full hierarchy would be quite painful and would make
>> it awkward to add a new Markers to existing Markers.  For example, if
>> something added "root" as the parent of "com" would you suddenly need to do
>> "root.com.foo.bar.MyMarker"?
>>
>
> This last example is great because it shows the confusing aspect of the
> whole deal.
>
> In one case, with loggers, we have parent-child hierarchies that work one
> way: root.com.MyLogger and com.MyLogger have nothing in common (except the
> root logger I suppose). But in the case of Markers, hierarchies work
> differently, where, if I understand I can change all com.foo.MyMarker1,
> com.foo.MyMarker2 into root.com.foo.MyMarker1, root.com.foo.MyMarker2? How
> am I supposed to get/find my maker if someone adds a parent to it? Can I
> always get Marker1, Marker2 by calling getMarker("Marker1")? If so, then
> the parents are really attributes or behave in a new way hierarchies don't
> usually do not behave. It is more like interfaces (implements) and classes
> (extends). So we need a different name for this relationship perhaps?
>
> Gary
>
>>
>> Ralph
>>
>>
>> On Apr 6, 2014, at 8:39 PM, Gary Gregory <garydgregory@gmail.com> wrote:
>>
>> > Before dealing with the complications of more than one parent, I think
>> one concept mere mortals should be able to deal with is being able to
>> define a marker hierarchy the same way we can define logger hierarchies
>> with dot names. So I can say MarkerManger.getMarker("com.foo.bar.MyMarker").
>> >
>> > Gary
>> >
>> > Gary
>> >
>> >
>> > -------- Original message --------
>> > From: Bruce Brouwer
>> > Date:04/06/2014 22:35 (GMT-05:00)
>> > To: Log4J Developers List
>> > Subject: Proposed change to MarkerManager API
>> >
>> > I hate changing API as much as the next guy, but there is an API in
>> MarkerManager that I think could be improved.
>> >
>> > MarkerManager.getMarker(name) gets a marker, optionally creating it if
>> it doesn't exist. I support this with no change.
>> >
>> > MarkerManager.getMarker(name, parents...) I have an issue with. It does
>> not in all cases return me a marker that has the parents specified. If the
>> marker already existed, it is simply returned with no changes made to the
>> parents. I propose removing this method and replacing it with...
>> >
>> > MarkerManager.define(name, parents...) This method will create the
>> marker with the specified parents if it does not exist. If it does exist,
>> it will change the parent list to be the list specified.
>> >
>> > Here's another reason I want to change this. Consider these two classes:
>> >
>> > public class A {
>> >   private final static Marker m = MarkerManager.getMarker("m", "p");
>> > }
>> >
>> > public class B {
>> >   private final static Marker m = MarkerManager.getMarker("m");
>> > }
>> >
>> > If class A gets loaded first, marker "m" will have parent "p". But if
>> class B gets loaded first, then marker "m" will have no parents. I
>> generally don't like relying on the exact order that classes are loaded
>> when the two classes aren't related.
>> >
>> > But if we consider my proposed change:
>> >
>> > public class A {
>> >   private final static Marker m = MarkerManager.define("m", "p");
>> > }
>> >
>> > public class B {
>> >   private final static Marker m = MarkerManager.getMarker("m");
>> > }
>> >
>> > Now the behavior is the same, no matter which class is loaded first. It
>> looks clearer to me as the definition of the marker happens in one place,
>> while class B is only interested in a reference to a potentially already
>> defined marker, but makes no statement about what parents it has.
>> >
>> > I also don't like the idea of the define method throwing an exception
>> if the marker already exists or getMarker returning null if the marker
>> doesn't exist; again for the reasons that I don't want class loading order
>> to impact behavior.
>> >
>> > I understand that if there are two statements defining a marker with
>> different parents, whichever one runs last is going to be the winner. It's
>> not great if that happens, but I shouldn't be defining a marker in two
>> places. In reality, the best thing would be to make class B reference the
>> marker field in class A. If I do that, then the current implementation
>> would work fine; I'm just thinking of the case where somebody doesn't (or
>> can't) do the best thing. Then, a distinction between get and define could
>> be helpful.
>> >
>> > Does this sound like an acceptable change that we could get into
>> log4j-api before GA?
>> >
>> > --
>> >
>> > Bruce Brouwer
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>



-- 

Bruce Brouwer

Mime
View raw message