> On 29 May 2015, at 4:39 pm, Lukasz Lenart <[email protected]> wrote: > > 2015-05-29 8:20 GMT+02:00 Joseph Walton <[email protected]>: >> >> As long as you’re making changes to logging, have you given consideration to >> making SLF4J the standard facade in Struts? That would allow making Log4j2 >> the preferred implementation without impacting anyone who wanted to stick >> with Log4j “classic”. > > That's the idea behind using Log4j2 - it has the same capabilities as > SLF4J or even more - so we can drop existing XWork logging facade and > use directly Log4j2 as a facade but I have doubts if it isn't too > early :) > > https://logging.apache.org/log4j/2.0/log4j-1.2-api/index.html > https://logging.apache.org/log4j/2.0/log4j-slf4j-impl/index.html > <https://logging.apache.org/log4j/2.0/log4j-slf4j-impl/index.html>
These links suggest that code written to the Log4j 1.x API can bridge to Log4j 2.x: > The Log4j 1.2 Bridge allows applications coded to use Log4j 1.2 API to use > Log4j 2 instead. and that Log4j2 provides an SLF4J backend: > The Log4j 2 SLF4J Binding allows applications coded to the SLF4J API to use > Log4j 2 as the implementation. (I can’t see any information about Log4j 2 providing its own facade, at first glance.) Given that, perhaps direct use of SLF4J’s API would make it easier to defer the choice of Log4j 2 or, for example, LogBack to runtime? That way there would be no compile-time dependency on Log4j2-specific API.
