Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Gradle plugin: generate logback.xml even with missing gatling resources directory

See original GitHub issue

Currenly, logback.xml is generated together with processGatlingResources task.

When resources directory (src/gatling/resources) is missing or users changes default location - the plugin may skip generation of logback.xml at all.

This may lead to improper logging configuration.

Improve generation of logback configuration

This is refactoring

Detect if gatling resources contains either logback.xml, logback.groovy etc. Currently the file location is hardcoded, this should be changed to analyze source directories and only limit sources to gatling resources.
If gatling resources has logback configuration - do nothing.
If gatling resources doesn’t include any logback config files - then
- generate logback.xml somewhere in build directory. A separate directory should be used, the file must not be put into build/resources as now. The generated file is better to place into build/generated to prevent interference with real resources processed by Gradle.
- As now generated logback.xml should use gatling.logLevel parameter to configure root logger level
Generated logback.xml should be passed to every forked JVM that executes Gatling via additional -Dlogback.configurationFile system property as logback docs explains.
Make sure current tests work.
Add test cases for other files, like logback.groovy etc.

Add possibility to configure HTTP requests via gatling configuration closure

This is new feature

Add a new parameter to gatling configuration closure
- named logHttp
- values: enum of [NONE, ALL, FAILURES]
during logback.xml generation logHttp should enable logger of HTTP request (io.gatling.xxx), according to passed value
create tests

Prevent logging misconfigurations and improve plugin UX

This is a new feature

If a user puts logback.xml or similar to resources folder, but the same times uses logLevel or logHttp parameters of gatling closure - plugin should throw an exception
- as an option - WARN log should be logged, without an exception.
create tests for this feature

Issue Analytics

State:
Created 3 years ago
Comments:20 (19 by maintainers)

Top GitHub Comments

1reaction

eshepelyukcommented, Sep 2, 2020

This issue became a mess, closing it.

Created #3948 #3949 #3950 #3951

0reactions

jonatan-ivanovcommented, Sep 13, 2020

Just for the record, the cause which started this issue seems to be the same problem as described in:

Top Results From Across the Web

Gatling logback file ignored by gradle.build - Google Groups

I'm calling Gatling as a *JavaExec* task from a Gradle build script. ... configuration files directly under src/test/resources (no *conf* folder anymore).

Logback can't find logback.xml even though it exists (on the ...

I set it up (using maven) and everything seems fine except that Logback reports it can't find the configuration file (but I'm able...

Configuration - Gatling

Configuration. Configure the logs with logback.xml, the configuration with gatling.conf, and the zip bundle command options. Gatling can be configured and ...

Debug Gatling Performance Test Scripts – 5 Essential Methods

Finally, you can configure Gatling logging by editing the logback.xml file. We created this file in the setup process for this project in...

Gatling Script & Create Gatling Project Using Maven Archetype

In this tutorial, we will understand the basic building blocks of a Gatling Script and create a Gatling Script Project in Maven /...