I'm not sure this is worth doing? One issue I can think of breaking
compatibility with the SLF4J API (and possibly commons-logging). I realize
it's not the Apache Logging Project's responsibility to maintain compatibility
with SLF4J, but I'm not sure it's worth doing at this late juncture for
Log4j-1.2.x with a future move to Log4j-2.0.
Note the main argument for this change...
> It's quite frustrating to find out in production that
> someone's
> overlooked this and we've lost a stack trace. The fix often just passes
> in
> t.getMessage() anyway.
...which I think is one of the reasons that, for SLF4J, Ceki chose to use
log(String, Throwable) rather than log(Object, Throwable), which wouldn't
suffer from being "overlooked" and "[losing] a stack trace". This looks to
have been a wise decision on Ceki's part.
Jake
On Thu, 15 Mar 2012 16:26:47 +0100
Christian Grobmeier <[email protected]> wrote:
On Thu, Mar 15, 2012 at 4:25 PM, Gary Gregory <[email protected]> wrote:
Question: how important is 100% bc for 1.2.x line? My assumption is:
very much... but well, as mentioned, I am not really opposed - just
careful
As long as I can do a couple of search and replaces, BC is not that
important to me in this case because the API is not big, it's a "nice to
have".
This is certainly a strong argument... along with the version number
change it would be possible. And how many methods might be removed? I
think they are only less
--
http://www.grobmeier.de
https://www.timeandbill.de
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
