• Change group id to com.typesafe
• Change to multi-module project
• Change artifact id of current code base (SLF4J) to scalalogging-slf4j

Why there is only AnyRef* in API?

  def debug(message: String, params: AnyRef*): Unit = macro LoggerMacros.debugMessageParams

is there any way to log something like this:

val i1 = 2
val i2 = 3
logger.debug("i1={} and i2={}", i1, i2)

whitout using toString method on i1 and i2?

http://www.slf4j.org/news.html - various concurrency improvements!

similar to all log level (error, warn,..).

Logger#info:

def info(message: String, params: AnyRef*): Unit = macro LoggerMacros.infoMessageParams

I think we must change params: AnyRef* to params: Any*

And in LoggerMacros#infoMessageParams: params: c.Expr[AnyRef]* to c.Expr[Any]*

In LoggerMacros#logParams:

• Change params: Seq[c.Expr[AnyRef]] to Seq[c.Expr[Any]]
• Then check if we need to convert params to type Seq[AnyRef] before delegate to underlying using WILDCARD_STAR syntax. See method akka.event.Logging#format1

Godaddy has an extension of the SLF4J logger that has some interesting features:

• https://github.com/godaddy/godaddy-logger
• http://onoffswitch.net/logging-easy/
• https://engineering.godaddy.com/logging-the-easy-way/

The most interesting is probably the composable logger -- you can assemble logging statements by using the with method:

logger.with(“first-name”, “GoDaddy”)
     .with(“last-name”, “Developers!”)
     .info(“Logging is fun”);

There's a number of other interesting features in there worth reading.

Unlike scala itself and akka which I am using the scalalogging jar file is missing OSGI export manifest headers which means I am unable to use it in OSGI environments

I have this in resolvers:
"Typesafe Repository" at "http://repo.typesafe.com/typesafe/releases/"

and these two in libraryDependencies:
"com.typesafe" %% "scalalogging-slf4j" % "1.0.1",
"com.typesafe" %% "scalalogging-log4j" % "1.0.1"

I still get this:
Failed to load class "org.slf4j.impl.StaticLoggerBinder", but according to the wiki here, only those 2 are needed. Did I miss something?

Hello,

I'm just getting started with Scala and want to use your library for logging.

I've followed the README and am able to see INFO log messages (e.g. logger.info("hello!")) in the console but when I change my log messages to any other level (e.g. logger.debug("hello!")) I don't see them.

I tried adding

logLevel in Global := Level.Debug

to my build.sbt and I get a lot more console output from the Scala libraries but nothing from my code.

What am I missing?

Thanks!

Not sure that scalalogging can work in conjunction with Java code. I tested scalalogging in a project with both scala and java code (see github url below) with an underlying slf4j-simple implementation and ended up with the following statement where the following displayed:

> test 
SLF4J: The following loggers will not work because they were created
SLF4J: during the default configuration phase of the underlying logging system.
SLF4J: See also http://www.slf4j.org/codes.html#substituteLogger
SLF4J: com.evolutionnext.Person
[info] PersonSpec:
[info] Using logging with inside of a model 
[info] - should display the log file
2013-05-01T08:58:13-0600 [pool-593-thread-5] [DEBUG] com.evolutionnext.Calculator - Adding 2 and 5
[info] CalculatorSpec:
[info] Using logging with inside of a service type class, calculator 
[info] - should add two ints and display the log
[info] Passed: : Total 2, Failed 0, Errors 0, Passed 2, Skipped 0
[success] Total time: 0 s, completed May 1, 2013 8:58:13 AM

This small project has two tests, one that tests a scala object and the other a java object.
Try it out by cloning https://github.com/dhinojosa/scala_logging_study and running test. You will find that it will randomly choose which class it will apply logging to.

• Could this repo get deleted?
• Or could the repository description more prominently mention the archival nature of the repo? -
  Maybe add a link to the new repo github.com/typesafehub/scala-logging as well?

It's easy to miss that the bottom of the README says to go to the new repo.

It's acting as a honeypot for well-meaning people like @unoexperto (and myself!).

We have abstract classes that want a logger mixed into it but don't care if it comes from Logging or StrictLogging, so adding a common ancestor would be nice:

trait HasLogging {
  protected val logger: Logger
}

trait Logging extends HasLogging {
...
}

trait StrictLogging extends HasLogging {
...
}

Given the raison d'être of scalalogging is performance, you're likely happy to learn that SLF4J 1.7.5 is a performance release, hence I think it should be included in the next scalalogging release.

http://www.slf4j.org/news.html
"The logger factories in most SLF4J modules namely in jcl-over-slf4j, log4j-over-slf4j, slf4j-jcl, slf4j-jdk14, slf4j-log4j12, and slf4j-simple now use a ConcurrentHashMap instead of a regular HashMap to cache logger instances. This change significantly improves logger retrieval times at the cost of some memory overhead. This improvement was requested in bug #298 by Taras Tielkes who also provided the relevant patch."

build.sbt:

version := "0.1"

name := "scalalogging"

scalaVersion := "2.10.0"

libraryDependencies += "com.typesafe" %% "scalalogging-slf4j" % "1.0.0"

src/main/scala/Main.scala:

import com.typesafe.scalalogging.slf4j.Logging

object Main extends App with Logging{
  logger.info("Hi: {}, {}", "foo", "bar")
}

$ sbt compile =>

[error] /home/giabao/o/dev/test-projects/scalalogging/src/main/scala/Main.scala:4: ambiguous reference to overloaded definition,
[error] both method info in trait Logger of type (x$1: String, x$2: <repeated...>[Object])Unit
[error] and  method info in trait Logger of type (x$1: String, x$2: Any, x$3: Any)Unit
[error] match argument types (String,String,String)
[error]   logger.info("Hi: {}, {}", "foo", "bar")
[error]              ^
[error] one error found
[error] (compile:compile) Compilation failed

http://www.slf4j.org/news.html

Static means that the log level is fixed at compile time and hence the macros can just elide the logging code for too low levels.

We had this issue in specs2 where Scalalogging was used with the -Yrangepos compiler option.

I suspect that the macros in Scalalogging need a bit of position setting to make this disappear.

Replacing the whole README.md by a redirect to version 2.x is a bit confusing for everyone still using Scala 2.10.

Also, it would be interesting to know whether there are other important differences between v1.1.0 and v2.x apart from the supported Scala version?

It'd be great if we'd have a 1.1 release. I've been depending on SNAPSHOT for the last 10 months...

Guys, could you please push 2.12 version to Maven/Sonatype repo ? Current version is "2.12.0-M5".

Thanks!

As documentation of scalalogging suggests, in order to use its macros
capabilities one should mix in Logging or StrictLogging trait.
But with such approach logger instance is attached not to the class that
really writes something to log, but to class of the current instance.
Therefore user looses ability to precisely configure which messages
write to log and which no.
Let me illustrate it with following code: https://gist.github.com/paul-lysak/6168137#file-loggerdemo-scala

SuperClassA/SubClassA hierarchy is extended from Logging trait,
and SuperClassB/SubClassB directly uses SLF4J with manual logger instantiation.
Consider following log4j.properties config file:

log4j.rootLogger=WARN, stdout
log4j.logger.SubClassA=INFO
log4j.logger.SubClassB=INFO
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%d [%t] %-5p %c - %m%n

It basically says that subclasses should display log messages up to INFO level,
while all others - only WARN. We aren't interested in INFO and so on - suppose
superclasses are from some framework and we don't care about its internals.

Now let's look at the output:

2013-08-06 22:35:27,311 [main] INFO  SubClassA - Hi, SuperClassA
2013-08-06 22:35:27,312 [main] INFO  SubClassA - Hi, SubClassA
2013-08-06 22:35:27,312 [main] INFO  SubClassB - Hi, SubClassB

Configuration worked as expected for B hierarchy (with manual logger instantiation) but it failed for hierarchy A (extended from Logging).

I really like how you managed to avoid redundant if()s with macros but I think that 2 things should be done:

1. Give convenient way to use the features without subclassing - for example, via custom LoggerFactory. Of course we can write all this "Logger(LoggerFactory getLogger getClass.getName)", but it's 7 letters longer than direct using of underlying logger library :)
2. Indicate in the documentation caveats of subclassing from Logging trait

Thanks!

scalalogging could provide logger methods that take a (Unit => String) rather than a String, then we don't need macros:

logger.debug(() => s"Some ${expensiveExpression} message!")

How do I use this module? Any link to example source would be very appreciated.

Please update README.md on Using ScalaLogging section to use 1.1.0 version on Sonatype OSS release

see https://oss.sonatype.org/content/repositories/snapshots/com/typesafe/scalalogging-log4j_2.10/
and
https://oss.sonatype.org/content/repositories/releases/com/typesafe/scalalogging-log4j_2.10/