Is logback really needed to use Gatling?

Gatling (Open-Source)
1

This is what I’ve been asked by some members of my team.

Let me digress. I have been tasked to integrate Gatling into an application as part of the company’s efforts to move towards a CD (Continuous Delivery) model where test code is kept in the same project structure as the application under test. That places my Gatling and Scala code under the src/test part of the project.

Developers on my team are highly suspicious of anything extra being added, and have pinpointed Gatling’s logback file as a liability because there are other apps and elements in the project that have closely related or conflicting logging implementations.

Naturally using Gatling in a setting like this has played havoc with running Gatling. The main project settings tend to override most settings in my logback file, so I had to get creative. I found I could change the root level appender in logback from INFO to ERROR and create a brand new log4j.properties file in my src/test/resources directory with a custom logging configuration for Gatling.

This arrangement was working pretty well, but now we are in code review, and Gatling’s logback file is the subject of much discussion.

What would be the ramifications of removing this file?

Would Gatling still function?

2

Gatling doesn’t depend on logback, it just ships it. It depends on slf4j, which is a logging API.
You then have to provide an implementation. Logback is the preferred one, but you can use a bridge that delegates to something else, such as slf4j-log4j12 for log4j 1.2.

3

Thanks for the info. I read the docs on slf4j's website, and it helped me understand better how it all fits together.

I ended up dropping the logback file and latching onto the same logger being used by the main project. After adding a log4j.properties file under sec/test/resources, I was able create a "custom" logging entry for Gatling. Having this enables me to use TRACE mode to debut my scripts.