The current logging is not user friendly. Any plan for supporting Slf4j in future?

[tarinidash]

In my understanding the only current logging option is to get a Logger instance from ExecutionContext. we have to pass this logger instance onto any dependency method incase we want to add more loggings in dependent methods too. Also java.util.Logger is an older way to manage logs in java application which is not user friendly. Here is a link - (https://stackoverflow.com/questions/11359187/why-not-use-java-util-logging)

slf4j(https://www.slf4j.org/) is a nice framework to manage logs in a user friendly way.Its also supports a better and user friendly string substitution for logs (https://www.slf4j.org/api/org/slf4j/helpers/MessageFormatter.html)

Is there any plan for supporting slf4j in future?

Ideally if Azure java functions can support lombook(@Slf4j) as first class citizen , we can annotate function and other classes with @Slf4j and rest of the logging is really easy to follow, rather than deriving Logger from ExecutionContext and passing it everywhere.

Let me know your thoughts.

[cepxy]

Its true, the current logging system is not very advanced. We have functions with several services and classes and would have to pass the logger from the context in the function root through every method call. This is just bad and not feasible.

It would really be great if modern logging frameworks could be used out of the box and fully integrated.

However it is already possible to use slf4j even with lombok. It just has some limitations and drawbacks.

I used @slf4j with logback. Log4j or other framewoks should work too. Just add logback and lombok dependencies to your pom and add a logback.xml configuration to your resources. In the configuration you can setup a file appender which points to a file on the home-folder that belongs to the function app:

<appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
   <file>D:\\home\\LogFiles\\slf4j\\logfile.log</file>
   <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
      <fileNamePattern>D:\\home\\LogFiles\\slf4j\\logfile.%d{yyyy-MM-dd}.log</fileNamePattern>
   </rollingPolicy>
</appender>

You should also add a console appender to see the logs via slf4j in the log streaming within the portal.

Known drawbacks:

• everything within a functionapp is logged into one logfile (the built in logging logs each function in its own file)
• logs in the logstreaming will be logged as information-level
• if a uncaught exception occurs this will NOT be logged via slf4j but appears in the standard log that belongs to that function. Also it seems that log messages belonging to that erroneous function call will not be stored in the slf4j file. I had cases where logmessages were missing after an uncaught exception.
• messages from the function app system will not be shown in the log4j log but the dedicated function log

[Vibhuti0910]

I am trying to use slf4j with log4j2 as the underlying logging framework. I have added a log4j2.xml in the classpath however the configuration specified in this file (the pattern layout) is not being picked up. So even though I do see the logs coming in, they are not in the pattern specified by me. This seems to be the default logging pattern, and I am not able to figure out how to override it. "[2020-10-16T09:48:37.052] INFO: Java HTTP trigger processed a request."

Is this something not supported by azure-functions-java-library altogether, or am I missing something in the config?

These are the dependencies I am using -

org.apache.logging.log4j log4j-to-slf4j 2.11.2

    <dependency>
        <groupId>org.apache.logging.log4j</groupId>
        <artifactId>log4j-api</artifactId>
        <version>2.13.0</version>
    </dependency>
    <dependency>
        <groupId>org.apache.logging.log4j</groupId>
        <artifactId>log4j-core</artifactId>
        <version>2.13.0</version>
    </dependency>
    <dependency>
        <groupId>org.slf4j</groupId>
        <artifactId>slf4j-jdk14</artifactId>
        <version>1.8.0-beta4</version>
    </dependency>