If you will note, Christian put in a plug for Log4j 2 quite some time ago in 
that Jira issue. From reading the issue it seems to me that Zookeeper must be 
using some convoluted processes in their build with all the problems they had 
getting patches to apply.  Also, they ship an executable binary, which makes it 
difficult to not include a logging implementation.  Flume also does this - 
which reminds me to open an issue with them.

Ralph

> On Aug 17, 2015, at 1:40 AM, Mikael Ståldal <mikael.stal...@magine.com> wrote:
> 
> It's OK if a library uses SLF4J properly. However, some libraries (even 
> Apache ones) uses SLF4J improperly by having a mandatory dependency on a 
> specific implementation (logj4 1 or logback) in their project. Such as 
> Zookeeper:
> 
> https://repo1.maven.org/maven2/org/apache/zookeeper/zookeeper/3.4.6/zookeeper-3.4.6.pom
> 
> This is very unfortunately since Zookeeper is a dependency for quite a lot of 
> other projects, and causes quite a lot of headache if you want to use Log4j 2 
> (you have to exclude dependencies). There is an old JIRA ticket for it, but 
> it has not been prioritized: 
> https://issues.apache.org/jira/browse/ZOOKEEPER-1371
> 
>> On Sat, Aug 15, 2015 at 2:27 AM, Ralph Goers <ralph.go...@dslextreme.com> 
>> wrote:
>> Gary,
>> 
>> Do you have something in mind?  While not hard, it is a fair amount of work 
>> for an application to switch to a different logging API. Granted, it is 
>> mostly just changing the call to get a Logger. But most applications should 
>> also take advantage of the new parameter syntax as well.
>> 
>> What was your experience with projects upgrading to commons lang3 vs commons 
>> lang?  I know quite a few people are still using commons httpclient vs the 
>> new version, and that has been around a lot longer than Log4j 2.  What I 
>> really hope is that we stopped projects from switching from log4j 1 to 
>> logback, although I am aware that many projects are using slf4j instead and 
>> letting their customers choose.  Frankly, if I hadn’t found limitations 
>> (such as the ability to use Messages) in SLF4J I would have used that as the 
>> API for Log4j 2 (I am quite happy we didn’t).
>> 
>> Ralph
>> 
>>> On Aug 14, 2015, at 2:34 PM, Gary Gregory <garydgreg...@gmail.com> wrote:
>>> 
>>> Something to think about after we get 2.4 out the door...
>>> 
>>> Do you think it appropriate for us to do some kind of outreach to other 
>>> Apache projects and say "hey, about about use log4j 2?"
>>> 
>>> Gary
>>> 
>>> -- 
>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org 
>>> Java Persistence with Hibernate, Second Edition
>>> JUnit in Action, Second Edition
>>> Spring Batch in Action
>>> Blog: http://garygregory.wordpress.com 
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
> 
> 
> 
> -- 
>  
> 
> Mikael Ståldal
> Senior backend developer 
> 
> Magine TV
> mikael.stal...@magine.com    
> Regeringsgatan 25  | 111 53 Stockholm, Sweden  |   www.magine.com 
> 
> Privileged and/or Confidential Information may be contained in this message. 
> If you are not the addressee indicated in this message
> (or responsible for delivery of the message to such a person), you may not 
> copy or deliver this message to anyone. In such case, 
> you should destroy this message and kindly notify the sender by reply email.  
>  

Reply via email to