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/