> On 29 May 2015, at 5:12 pm, Christoph Nenning <[email protected]> > wrote: > >> >> 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. >> > > > From the log4j2 front page: > > http://logging.apache.org/log4j/2.x/ <http://logging.apache.org/log4j/2.x/>
Ah, great. I think http://logging.apache.org/log4j/2.x/log4j-api/apidocs/ <http://logging.apache.org/log4j/2.x/log4j-api/apidocs/> is what I was looking for, as documentation of the org.apache.logging.log4j:log4j-api artifact. > Log4j2 wants to provide the same benefits as slf4j does. AFAIK slf4j is a > one man show while log4j2 has a bigger team and is backed by the ASF. It’s a shame to end up with two separate logging facades. Despite being a one-man project, SLF4J has a substantial number of contributors: https://github.com/qos-ch/slf4j/graphs/contributors <https://github.com/qos-ch/slf4j/graphs/contributors> - 36, to 7 for https://github.com/apache/logging-log4j2/graphs/contributors <https://github.com/apache/logging-log4j2/graphs/contributors>). It’s also widely proven, and stable. That said, the Log4j 2 to SLF4J adaptor (https://logging.apache.org/log4j/2.0/log4j-to-slf4j/index.html <https://logging.apache.org/log4j/2.0/log4j-to-slf4j/index.html>) looks like it’ll make simple to use Struts with an existing SLF4J environment. Then everyone can get behind coding to a simple API and picking the best logging implementation at runtime. Thanks for the pointers; looking forward to seeing simplification in Struts.
