Improvements to the logging capabilities of DataWeave

[GauthierPLM]

Current state

Currently, the logging capabilities of DataWeave are pretty limited and do not leverage everything the Java platform has to offer. The log function is pretty simple: it accepts a value, and optionally a message to prepend to the value. There are no way to customise the log level or the category of the log.

In a production context, this limit the use cases of the log function as log acts like a println() more than like a real logging utility.

Having no way to only log some text without printing the value is also an important feature missing from DataWeave log function.

Proposal

To improve DataWeave logging capabilities, I would suggest either extending the log function, or offer a new logging module that would offer the following:

• Logging helpers to log a message such as Logging::error, Logging::warn, Logging::info, Logging::debug, Logging::trace.
• A head parameter on every functions to set the log category.
• An optional head parameter to specify the log level on a generic log function.
• A set of methods that would return the value parameter but not print it.

This would result in the following new functions:

• Logging::log(category: String = "", level: String = "INFO", prefix: String = "", value: T): T
• Logging::error(category: String = "", prefix: String = "", value: T): T
• Logging::warn(category: String = "", prefix: String = "", value: T): T
• Logging::info(category: String = "", prefix: String = "", value: T): T
• Logging::debug(category: String = "", prefix: String = "", value: T): T
• Logging::trace(category: String = "", prefix: String = "", value: T): T

These methods would be doubled with another set allowing not to print the value passed while still returning it:

• Logging::log(category: String = "", level: String = "INFO", prefix: String = "", value: T, logValue: Boolean): T
• Logging::error(category: String = "", prefix: String = "", value: T, logValue: Boolean): T
• Logging::warn(category: String = "", prefix: String = "", value: T, logValue: Boolean): T
• Logging::info(category: String = "", prefix: String = "", value: T, logValue: Boolean): T
• Logging::debug(category: String = "", prefix: String = "", value: T, logValue: Boolean): T
• Logging::trace(category: String = "", prefix: String = "", value: T, logValue: Boolean): T

These methods signatures would be compatible with the existing log function, offering an easy transition while remaining coherent with the existing core library.

[machaval]

What is the usage of Category also the logValue Boolean flag looks weird to me. What a user will control logging on their code?

[GauthierPLM]

@machaval the usage of the category would be the same as the category field of the Logger component. Described as:

Optional setting that specifies a category name that it adds to log4j2.xml file. For example, you might use a category to route your log messages based on your category, or you might set log levels based on category.

---

The logValue boolean would help in logging information that do not need to log the value itself, e.g. to know which branch of a if or case statement was visited, while still returning the value and thus keeping the behaviour of the current log function. Having such logs is very common in most application, usually on the DEBUG log level.

I created a small DataWeave code to illustrate this, in which I only want to log something when a string length is 5 or more:

%dw 2.0

fun myLog(prefix: String = "", value: Any, logValue: Boolean): Any =
    if (logValue == false) (log(prefix) then value) else log(prefix, value)

output application/json
---
if (sizeOf(payload.message) >= 5) myLog("String length >= 5", payload.message, true)
else payload.message

In this example, "String length >= 5" will be logged without the actual value if payload.message' length is >= 5.

It's easily doable in a Mule application using the Logger component that always pass the message without touching it while allowing to log its values, but a similar behaviour is not possible in DW without writing a custom function as in my example.

[machaval]

Hi @GauthierPLM Thanks for the clarification. The category looks like a log4j concept and this logging mechanism should be framework independent. On the logValue concept looks like a workaround to the no side effect issue in DW. I understand the use case and the problem. But I would try to look for something more declarative. But I agree that we should improve our logging capabilities and the initial proposal looks like a good starting point.

Thanks for the feedback.