Pure Scala logger for the Scala Platform

Scala Platform
1

Is there some support for considering https://github.com/outr/scribe or another pure Scala logger as a candidate for the Scala Platform?

Logging has been a mess on the JVM ever since the java.util.Logging non-standard as a replacement for log4j and since then it has gotten worse common-logging and a bit better with slf4j.

The Scala community do better as long as current Java code can log through the Scala logger as with the slf4j adapter for the JVM provided by Scribe.

3 Likes
2
  1. Lots of references to using macros. Are these whitebox? Does this have a future in Scala 3.0?
  2. Java API – some would prefer a Log4j2 api entry point rather than a slf4j one as it is slightly more feature rich. Does it support line number / class extraction via this entry point, since macros aren’t available?
  3. There are comparisons to log4j2 performance, but no note about whether the logging is non-blocking (log4j2 has an async LMAX disruptor based logger option to prevent app threads from ever blocking).
  4. For those working outside the JVM, I’m sure a pure Scala logger would be appreciated. For those of us working only in the JVM with mixed Scala/Java/other languages its going to be a harder sell.
3
  1. There are comparisons to log4j2 performance, but no note about whether the logging is non-blocking (log4j2 has an async LMAX disruptor based logger option to prevent app threads from ever blocking).

The Readme states among the features:

  1. Asynchronous logging support. Scribe’s logger is very fast, but if real-time performance is critical, the asynchronous logging support completely removes logging impact from your application’s thread impact.

I guess synchronous logging is the default behavior and asynchronous logging is done via the https://github.com/outr/scribe/blob/master/core/jvm/src/main/scala/scribe/handler/AsynchronousLogHandler.scala class.

4

Java API – some would prefer a Log4j2 api entry point rather than a slf4j one as it is slightly more feature rich. Does it support line number / class extraction via this entry point, since macros aren’t available?

Yes, although it’s done at runtime with an expensive call to get the stack trace. Use %l in your log layout. Log4j – Log4j 2 Layouts

I have a change to the scala API to make this happen at run time, but it hasn’t been merged. exposes the location part of the Message to loggers by shawjef3 · Pull Request #152 · apache/logging-log4j2 · GitHub

5

I’m open to considering changes in Scribe if it would benefit the more general use. However, not much effort to support SLF4J or Log4J has been defined because of the design flaws of their API. We are stuck with runtime stack investigation for trace detail without Macros.

6

Is it not possible to add compile-time trace details to Scala 3? I think it is a very reasonable request (or yet we risk leaving more projects behind when jumping from 2.14 to 3).

2 Likes
7

@scoronpo, it can be done via Macros already and is done in Scribe. In fact, Scribe includes not only line numbers but column numbers for more functional code as well.

8

The question isn’t whether it can be done via Macros already in scala 2, the question is how it will be done in scala 3.

4 Likes
9

Hi guys,

Let me add my ten cents:

  1. we need macros, scala has no future without macros
  2. All the logging needs can be satisfied with whitebox macros
  3. I would vote against a standard logger for scala. Logging is a big subject and at the moment scala allows you to do a lot, like this library (disclaimer: I’m the author) allows you to implement zero-cost structural loggers. At the same time it wouldn’t be wise to include a very advanced macro-based logging machinery into standard library and it would be dumb to include a trivial API just to have it.

A logger cannot be unopinonated. And I think that it’s better to give people freedom of choice than to push an opinionated way of doing things. It already happened many times before.

1 Like
10

I agree, the ability to make high level extension is a killer feature of scala.
But I disagree that whitebox macros is a killer feature, because it is too complicated, it allows to change scala syntax. I personally don’t need that kind of power. I prefer better idea integration and more stable work.(I still need the ability to inject custom type)

What killer feature cannot you make with black box macros in logging?

11

Eh, sorry. I’ve been typing in hurry, it’s just a typo. We need and use blackbox macros. Everything Scribe does can be done with bb macros as well. At the same time dotty must have a macro mechanism so there is no point in saying

Lots of references to using macros. Are these whitebox? Does this have a future in Scala 3.0?

Scala itself has no future without macros, IMO.

Regarding killer feature: we extract structure. For free. And turn it into json/events/whatever. For free.

12

For free

Meaning, automatically from ordinary string interpolations:

logger.log(s"service $s doing job $y")

Will create a json with structure such as:

{ 
  "s": <s.toString>, 
  "y": <y.toString>, 
  "@template" = "service ${s} doing job ${y}" ,
  "@message": <rendered>,
  "@event": { "timestamp": ..., ... }
}

and print a colored message with variables to the console.

https://izumi.7mind.io/v0.5.50-SNAPSHOT/doc/logstage/media/00-logstage-sample-output-string.png

13

While Scala 3 will have some form of blackbox macros, I don’t think what is currently implemented in dotty provides access to things like line numbers.

14

It does: Implement SourceLocation using Tasty reflect by nicolasstucki · Pull Request #1 · dotty-staging/minitest · GitHub

1 Like
15

Oh right, I forgot about Tasty reflection. That’s planned to stay then?

16

So far, yes.

17

What about object names?