Currently RollingFileLogWriter itself is declared as open, but all interesting facilities are actually private.
The only "open" fun appears to be log, which makes inheritance redundant (one could use composition instead of inheritance).
I propose the crucial functionality should be made protected instead - at least loggingChannel.
For instance, currently it's not easy to actually provide a custom format for throwable as it bypasses messageStringFormatter (which can actually be configured) and goes straight to bufferLog. With a protected loggingChannel one could derive an object from RollingFileLogWriter, write their own log function and push the formatted message directly with loggingChannel.trySendBlocking(Buffer().apply { writeString(log) }). The last part is currently impossible, because th crucial loggingChannel is private.
The only other solution I can think of is to actually incorporate throwable into message, but this is hacky and not always desired.
This ties into a separate issue that it's not possible to provide custom format for Throwables.
For instance, imagine a structured log format that serializes messages like this:
val formatter = object : MessageStringFormatter {
override fun formatMessage(severity: Severity?, tag: Tag?, message: Message): String {
val timestamp = clock.now().format(DateTimeComponents.Formats.ISO_DATE_TIME_OFFSET)
return json.encodeToString(
StructuredLogMessage(
timestamp,
severity.toString(),
tag?.tag,
message.message
)
)
}
}When this formatter is used with a Throwable, the log writer adds a nicely formatted, structured message, followed by an unstructured stack trace. Instead, it would be nice if we could provide a way to format the Throwable, or get the Throwable as an argument in MessageStringFormatter::formatMessage. The most straightforward workaround would be to manually format the message in log, but this circles back to all the crucial facilities being hidden.
Currently RollingFileLogWriter itself is declared as open, but all interesting facilities are actually private.
The only "open"
funappears to belog, which makes inheritance redundant (one could use composition instead of inheritance).I propose the crucial functionality should be made
protectedinstead - at leastloggingChannel.For instance, currently it's not easy to actually provide a custom format for
throwableas it bypassesmessageStringFormatter(which can actually be configured) and goes straight to bufferLog. With aprotected loggingChannelone could derive an object fromRollingFileLogWriter, write their ownlogfunction and push the formatted message directly withloggingChannel.trySendBlocking(Buffer().apply { writeString(log) }). The last part is currently impossible, because th crucial loggingChannel isprivate.The only other solution I can think of is to actually incorporate throwable into message, but this is hacky and not always desired.
This ties into a separate issue that it's not possible to provide custom format for Throwables.
For instance, imagine a structured log format that serializes messages like this:
When this formatter is used with a
Throwable, the log writer adds a nicely formatted, structured message, followed by an unstructured stack trace. Instead, it would be nice if we could provide a way to format the Throwable, or get the Throwable as an argument inMessageStringFormatter::formatMessage. The most straightforward workaround would be to manually format the message inlog, but this circles back to all the crucial facilities being hidden.