search

testcontainers / testcontainers-java

Testcontainers is a Java library that supports JUnit tests, providing lightweight, throwaway instances of common databases, Selenium web browsers, or anything else that can run in a Docker container.
https://testcontainers.org
MIT License
8.03k stars 1.65k forks source link

Easier way to configure logging #637

Open lburgazzoli opened 6 years ago

lburgazzoli commented 6 years ago

So by default test containers logs in the following form:

14:42:17.885|INFO |🐳 [gcr.io/etcd-development/etcd:v3.3] - Creating container for image: gcr.io/etcd-development/etcd:v3.3
14:42:18.256|INFO |🐳 [gcr.io/etcd-development/etcd:v3.3] - Starting container with ID: e2f3eb78d0eb6b073271abcf30a76e675fe35f2212684935a36f3a28d4ee9a14

So if I want to log only warning I have to configure i.e. log4j2 as follow:

<Loggers>
    <!-- package loggers -->
    <Logger name="org.testcontainers" level="INFO" additivity="true"/>
    <Logger name="🐳 [gcr.io/etcd-development/etcd:v3.3]" level="WARN" additivity="true"/>

    <!-- main logger -->
    <Root level="INFO">
      <AppenderRef ref="STDOUT" />
    </Root>
  </Loggers>

Which means that I have to include:

So if I do upgrade the image or if I need to test against different images, I have to change also the logging configuration if I do not want to see testcontainers logs.

Maybe it is better to put the image name using MDC so one may decide to show it or not.

DmRomantsov commented 6 years ago

Hi! Any response?

kiview commented 6 years ago

This code is responsible for logger creation: https://github.com/testcontainers/testcontainers-java/blob/23478fac6f86c4dd8d0eb964386089144cb26f6e/core/src/main/java/org/testcontainers/utility/DockerLoggerFactory.java#L11-L25

I don't have any experience how to leverage MDC in the context, so an example or a PR (or just PR draft) would be helpful.

lburgazzoli commented 6 years ago

This is a possible example:

https://gist.github.com/lburgazzoli/2bfc2a1ed7967e9f80b236f5e0e881b4

As MDC relies on ThreadLocal and I do not know the threading model used by testcontainers, I've decorated the Logger instance so that diagnostic info are added on each invocation if they are done in a new thread.

I've not tested it as building testcontainers-java fails for the following reason:

$ ./gradlew install 
> Task :bom:verifyLombok FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':bom:verifyLombok'.
> Verification of Lombok JAR failed!

  Local JAR file:    /home/lb/.gradle/caches/modules-2/files-2.1/org.projectlombok/lombok/1.18.2/524e0a697e9d62950b2f763d88d35cd8dc82a9a1/lombok-1.18.2.jar

  Expected checksum: c5178b18caaa1a15e17b99ba5e4023d2de2ebc18b58cde0f5a04ca4b31c10e6d
    Actual checksum: f13db210efa2092a58bb7befce58ffa502e5fefc5e1099f45007074008756bc0

Even after having deleted the gradle cache.

lburgazzoli commented 6 years ago

A new version with a proxy which reduce the amount of code:

https://gist.github.com/lburgazzoli/cedc572465061994827a48682b6ba6e4
rnorth commented 6 years ago

@lburgazzoli I like this suggested improvement, and I think the proxy-based approach is a good idea.

Are you still having problems with the Lombok JAR in your local build? That is a strange issue...

lburgazzoli commented 6 years ago

It fails when using

./gradlew install -x check

but it succeed with

./gradlew publishToMavenLocal -x