Re: [infinispan-dev] logger and ineritance
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache