Re: Log42j

[Joseph Walton <jw...@atlassian.com>]

> On 29 May 2015, at 5:12 pm, Christoph Nenning <Ch...@lex-com.net> 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.