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 12:48:40 GMT
As I think about it more, I like the fluent idea better. This way I would
get to choose if I wanted my parents to add to or replace the existing
parents. So make both setParents and add methods return "this".

Actually, there is one thing about the current marker implementation that
thoroughly confused me. slf4j used to call the relationships "children",
but they have since deprecated that name and now call them "references".
log4j calls them "parents". And instead of "isInstanceOf", slf4j calls that
method "contains". Because of this, I originally thought that the
log4j-slf4j-impl was written backwards. I had to write some test code to
prove to myself that the names don't in fact matter one bit. In that
regard, I would prefer that instead of having "getParents" and
"isInstanceOf", we have "getReferences" (like slf4j) and "references". It
would fit better to what I think this is actually modelling, a directed
graph, rather than a parent child relationship. But my guess is that will
be seen as too big of a change.


On Mon, Apr 7, 2014 at 7:46 AM, Bruce Brouwer <bruce.brouwer@gmail.com>wrote:

> 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
>



-- 

Bruce Brouwer

Mime
View raw message