Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some errors cause a NoClassDefFoundError and the real error is hidden #1872

Open
amirabiri opened this issue Sep 14, 2019 · 4 comments
Open

Comments

@amirabiri
Copy link

In certain cases a test may fail with a NoClassDefFoundError, and it's a nightmare to find the real error.

For example:

static final PostgreSQLContainer = PostgreSQLContainer("postgresxxx:11.5") 
    .withDatabaseName("netonomy")
    .withUsername("postgres")
    .withPassword("password");

Then running gradle test results in:

com.example.SomeIntegrationTest > testPostgres() FAILED
    java.lang.NoClassDefFoundError: Could not initialize class com.example.SomeIntegrationTest

To find out the actual error, it was necessary to run Gradle with --info. I only used a bad image name here as an example to reproduce - the real error was "Docker environment should have more than 2GB free disk space", and it happened only on the CI build agent - so this was a real nightmare to diagnose!

What makes this even more difficult to pin down is the fact that even removing the @Testcontainers and @Container still results in the exact same behaviour!

The reason for all of this, is the fact that GenericContainer's constructor calls this.setDockerImageName() which in turn calls getDockerImageName() which actually attempts to get the image: https://github.com/testcontainers/testcontainers-java/blob/master/core/src/main/java/org/testcontainers/containers/GenericContainer.java#L1057

IMO this is an action that should not take place in a constructor - this should happen only later during start(). Either way there ought to be some better solution, because diagnosing errors this way is a nightmare.

@bsideup
Copy link
Member

bsideup commented Sep 14, 2019

Hi @amirabiri,

We're aware of that problem. Some old time ago, a decision was made to fail fast if image fails to resolve.

We do plan to change it to resolve on start, but delayed it until 2.x. Although we could do it sooner, e.g. as part of #1345, see this conversation:
#1345 (comment)

@rnorth
Copy link
Member

rnorth commented Sep 16, 2019

We do plan to change it to resolve on start, but delayed it until 2.x. Although we could do it sooner, e.g. as part of #1345

Yes, I think we can and should

@almed4
Copy link

almed4 commented Sep 10, 2021

Any progress on this? I would never have been able to solve my problem without reading @amirabiri's comment.

@jeantil
Copy link

jeantil commented Mar 3, 2024

Hello,

It looks like #1345 did not change the policy on image resolution and based on the 2.x milestone activity, 2.x seems to have been stalled for around 5 years.

Are there any recent plans regarding this issue ?

thanks,

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants