Log4j file appender in custom Gradle plugin stops writing after gradle clean

Help/Discuss
1

I’m distributing a custom Gradle plugin that uses log4j for logging. I have an XML configuration bundled inside the plugin.

Everything works well initially, and the file appender correctly writes log messages to the specified file. However, as soon as someone runs gradle clean, the file appender stops writing to the log file entirely, although logs appear in the console as expected. My understanding is that after a gradle clean when the file appender points to the build directory (like I want it to), the existing file appender no longer has a valid file handle and will stop writing logs, so I tried forcing a reconfiguration during task execution with something like:

fun initializeLogger(loggingLevel: () -> String, loggingDirectory: () -> String): Logger {
    LoggingSetup.setLoggingLevelProperty(loggingLevel())
    LoggingSetup.setLoggingDirectoryProperty(loggingDirectory())
    val logger = LogManager.getLogger("org.myplugin")
    (LogManager.getContext(false) as LoggerContext).reconfigure()
    return logger
}

But to no avail.

I also understand that the easiest way is to let Gradle handle things on its own, but the behaviour I want to program, if possible, is to have my logs as a build output, basically.

Has anyone encountered this behaviour before, or can anyone suggest a way to keep the file appender active after running a clean? Any insights or best practices for configuring Log4j within a Gradle plugin would be greatly appreciated!

2

Best practice is to not do that, but let Gradle handle the log messages, so I guess it is pretty unlikely that someone did what you try and if someone then probably not too likely that one person finds this thread. :smiley:

Besides that, it is probably more a question for log4j than for Gradle.

The question is also whether you are on *nix or Windows.
My guess would be that if you do that on Windows the clean will fail if Log4j still has the log file open to write to it, but on *nix the file entry gets deleted while Log4j still has the handle to the inode and can happily continue writing to it. Whether it could detect that is more a question to log4j not Gradle.