[infinispan-dev] logger and ineritance

Galder Zamarreño galder at redhat.com
Mon Dec 19 05:17:18 EST 2011


On Dec 16, 2011, at 4:57 PM, Mircea Markus wrote:

> Re: your first point here: http://bit.ly/tl2q14
> 
> With this approach not only that  an additional method call is added (hardly a big performance fault, but still..) but for me it makes it harder to compare the logs with the code, as the class that contains the code might be different than the class that "runs" the code. 

There are situations where this is handy such as https://github.com/infinispan/infinispan/pull/729. Here we have two versions of the protocol, version 1.0 and 1.1.

1.1 is almost identical to 1.0, the changes are primarily around the hash distribution headers. The rest is the same.

Assumming you have two classes, Code10 and Codec11 and Codec11 delegates to Codec10 for the majority of work, the logs will show a mix of messages from Codec10 and Codec11 which seems a bit confusing, particularly if you're not familiar with the code.

By making Codec10 log with the logger of Codec11 when version 1.1 is in use, I agree that you see log messages that don't come from Codec11, but you get a clearer sense of which codec is in use, whether 1.0 or 1.1.

> In my case at least, it's important to be able to compare the logs with the code fast - as this is the way I use the logs.
> 
> OTOH I agree that the logs don't tell you straight away the runtime class where the code was ran - but TBH I don't remember that being an issue for me. I remember though being annoyed by "overridden" loggers in a previous project - hence my email :-)
> I'd be very curios hear other opinion on this, especially Galder's as I imagine he did a fare share of log reading back in the days.

See above.

> 
> Cheers,
> Mircea  
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache




More information about the infinispan-dev mailing list