I just read akka#26537 by @patriknw which describes a decision to switch from classic’s EventStream to SLF4J for akka-typed (possibly tentative?).
This is of interest to me because I am currently writing a custom logging backend that sends events to a REST API. For this reason the classic EventStream logging infrastructure is appealing: the logger is initialized by spawning an Actor and thus has full access to the ActorSystem, Http, etc.
Should implementing loggers for the classic logging EventStream be considered deprecated or otherwise discouraged in favor of SLF4J?
If SLF4J is in fact the way forward, any thoughts/advice how to implement e.g. a logback Appender that has access to the ActorSystem? It seems impossible to configure this directly via the logback.xml; such an Appender would have to be initialized programmatically after the ActorSystem is created.
Thanks in advance for some direction on this issue.
Classic logging with EventStream will not be deprecated (as far as we know now) and logging in existing classic modules will continue to use it. However, new -typed modules are not (always) using it so you will not capture all logging that way. Therfore better to implement this with a logback appender.
You can have an Akka extension that is loaded at startup and registers the ActorSystem in the logger appender.
This is a critical caveat. It sounds to me like although logging via EventStream will continue to be supported, implementing new logging backends for EventStream really should be deprecated IMHO.
I found inspiration in Spring Boot where they add custom rules to the logback.xml parser that enable referencing Spring properties from inside the XML. So now I am imagining an Akka extension that loads a logback.xml with Akka-specific parsing rules to access Akka config values from within the XML as well as to register the ActorSystem with appenders.