Journal's README.md states that It uses Logback as the default backend, but you can supply any backend you want, however there appears to be no documentation or examples of how to supply an alternative backend (Log4j2 for example). Could such documentation be added?

How much work is this? If I wanted to PR this in, what would I need to do?

It would be helpful if http://verizon.github.io/journal/ were updated to point to io.verizon.journal instead of oncue.journal

Have you done performance benchmark on the library? How's the CPU usage and throughput compared to a conventional logging library?

The current version on Maven central (that the badge in the README references) is for io.verizon.journal#core_2.11;2.3.15, but the documentation site still says to look for oncue.journal on bintray.

Noticed that there is support for Scala 2.11 in recent commits, but only 2.10 in released versions in Bintray.

Does that mean that 2.11 will be supported in an upcoming release fairly soon?

This is perhaps due to the threaded/asynchronous nature of the journal library, but fatal exceptions are not logged unless they are handled specially. This issue may be more one of documentation, as a workaround exists, but it may be worth investigating whether it would be possible to deal with the problem so the workaround was not necessary.

To reproduce this issue with 2.2.1, run:

import journal._

object RapidDeath extends App {

  val log = Logger[this.type]

  try {
    throw new Exception("Oh no!")
  } catch {
    case t: Throwable => log.error("Died", t)
  }

}

No log file is written, perhaps because the application terminates (along with the logger threads) before any buffers are flushed and a message is written.

Conversely, you can ensure that the exception will be logged with:

import journal._

object RapidDeath extends App {

  val log = Logger[this.type]

  try {
    throw new Exception("Oh no!")
  } catch {
    case t: Throwable => log.backend.error("Died", t)
  }

}

Note the direct call to log.backend in the catch block. This appears to bypass the threading, ensuring the message reaches the log before the application terminates. I think this is mostly a reasonable workaround, so long as your application is sufficiently simple to have just one or two places where this specialized try/catch/log behavior is necessary, but it might merit a note in the documentation.