I’m calling Gatling as a JavaExec task from a Gradle build script. The project follows traditional java structure (src/main and src/test at top levels), and I have placed my Gatling logback and other configuration files directly under src/test/resources (no conf folder anymore).
The gradle build script also has a sourceSets declaration in build.gradle, and I’ve added a custom task to print out location of each test classpath file. The println statements indicate that my files in test/resources are being found by the runtime classpath.
However, when I run the Gatling task (which is of type JavaExec), the logging level of my logback.xml is ignored by Gradle. For example I’ve set the logback file to “log failed request and response only”, but when I run the task, the console shows INFO statements for every single thing Gatling does. I think the host project is set at a more verbose level to support a requirement of operations for their monitoring tools, so it seems any fix I implement would need to be done from the Gatling side.
One thing I have noticed is when I run Gatling task, the console displays a series of warnings about “multiple classpath bindings” for slf4j. I have some a number of Gradle projects that use Gatling and others that do not. This warning only appears when Gatling is part of the project, so it makes me wonder if a Gatling dependency is triggering this conflict with the host project. It looks as if stronger measures are needed to isolate Gatling’s runtime configuration from the Gradle project’s runtime when sourcecode for both lives in the same project space.
What are my options for making my resource configuration files visible to io.gatling.app.Gatling?
I mentioned isolation because that seemed most natural, but there might be others, and I’m open to suggestions.