While that is true, if an application uses our Logger API and recompiles and
they actually use one of the new methods there will be a problem when they run
with the other Logger implementation. So, yes it would be compatible if all
they do is upgrade the log4j version and don’t leverage any of
Hm... I think I'll use the stock throwing() API and its underlying stock
THROWING marker.
I won't worry about possible future issues now, YAGNI!
WRT adding methods to log4j-api interfaces, it sounds like would be locked
out from doing so until 3.0 BUT look at
http://docs.oracle.com/javase/specs/j
If you add those methods and someone is implementing their own Logger without
extending AbstractLogger then they will have a problem (i.e. - you are breaking
binary compatibility). Also, how are you going to implement error(Marker,
Throwable)? logMessage requires the message parameter. It will
And now I'd also like to have
a org.apache.logging.log4j.Logger.throwing(Throwable, Marker) so I can
provide my own marker instead of the canned one.
Thoughts on that?
Gary
On Fri, Mar 20, 2015 at 3:35 PM, Gary Gregory
wrote:
> I need:
>
> org.apache.logging.log4j.Logger.error(Marker, Throwabl
I need:
org.apache.logging.log4j.Logger.error(Marker, Throwable)
But we have:
org.apache.logging.log4j.Logger.error(Marker, String, Throwable)
Thoughts on adding the new APIs (for all levels)?
Gary
--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Secon
