Sure.  Like you said, it's already pulled in as a dependency from other third 
parties so there's no real penalties in using it.

--Alex

> -----Original Message-----
> From: Darren Shepherd [mailto:darren.s.sheph...@gmail.com]
> Sent: Tuesday, September 17, 2013 11:56 AM
> To: dev@cloudstack.apache.org
> Subject: [PROPOSAL] standardize on or at least allow use of slf4j going
> forward
> 
> Currently all logging in ACS is done using log4j APIs.  slf4j is already 
> packaged
> as a transitive dependency in ACS.  I propose that going forward we starting
> using slf4j APIs as opposed to log4j APIs.
> 
> For those who don't know, slf4j is a logging abstraction API.  In the world of
> java logging abstractions there are basically three frameworks
> java.util.logging (JUL), jakarta commons logging (JCL), and simple logging
> facade for java (slf4j).  Most people gravitate towards slf4j these days [1].
> JUL isn't really that usable and JCL requires you to do "if (log.isDebug())"
> everywhere to avoid the overhead of string concatenation.
> 
> Its important to note that I'm not saying we stop using log4j.  At runtime 
> log4j
> will be still used as the implementation, I'm merely talking about the API 
> that
> we code against.  It's a generally good practice to use a logging abstraction
> API and its some what of shame that one was never put in place to start with.
> 
> At one point we can decide if we want to switch 100% to slf4j.  There is a
> utility to convert your source code from log4j to slf4j.  Right now I just 
> want
> to "bless" using slf4j APIs as okay.
> 
> Darren
> 
> [1] Projects depending on SLF4J at http://www.slf4j.org/

Reply via email to