Enable dev services for all named mongodb-client connections

[evanchooly]

fixes #25278

[evanchooly]

Interesting follow up question here (and perhaps a change of direction): in order to create a named client, there has to be something in application.properties referencing that name. That something can't use connection-string or devservices won't start something up for it. Now, generally speaking, the likelihood of not having any configuration for the other clients is slim. with prod entries there will be at least a connection-string and credentials and the like so that's not a problem. But if the difference in environments is only that connection and credentials and everything else is defaulted (fairly likely) having a dummy entry in the config just to surface that named client name seems a bit lame. Could we infer the existence of a named client by discovering uses of @MongoClientName and backfilling that client using only that name and the default values of the config? In essence, lazy init'ing the named client and letting devservices have its usual go at it.

[geoand]

Could we infer the existence of a named client by discovering uses of @MongoClientName and backfilling that client using only that name and the default values of the config? In essence, lazy init'ing the named client and letting devservices have its usual go at it

Probably, but I am thinking that it might break stuff, so I would like to avoid it.

[geoand]

I think we need the test to have both named and non-named clients

[loicmathieu]

+1
Do we have a way to access the devservices information from a test to check that 2 devservices has been started ? The default and the named one ?

[evanchooly]

The default client is injected in PojoResource

[evanchooly]

we can have only one unnamed client and that will have to be done either via dev services or MTR. I pushed a different config that uses MTR for the default and a named one and two named clients using dev services. This covers, i think, all the combos except for default via dev services. I've verified this "manually" but because the config has to be this or way that, it's not "permanently" configured this way.

[evanchooly]

Could we infer the existence of a named client by discovering uses of @MongoClientName and backfilling that client using only that name and the default values of the config? In essence, lazy init'ing the named client and letting devservices have its usual go at it

Probably, but I am thinking that it might break stuff, so I would like to avoid it.

actually, the more i think about this the less i like it. typos would be a nightmare. (even though those names should be held in constants somewhere. ;) )

[evanchooly]

bump

[geoand]

The affected test is not using dev services as the connection string has been set - mongo is being spun up by io.quarkus.test.mongodb.MongoTestResource

[geoand]

LGTM!

[geoand]

Hm... The test failure is suspicious

[evanchooly]

Hm... The test failure is suspicious

No docker on CI ...

[loicmathieu]

@evanchooly there is no docker on Windows CI. That's why we don't use testcontainers for MongoDB tests but the testresource. But even the testresource didn't works very well on Windows due to some issue on flapdoodle side so we ends up disabling the test on Windows: @DisabledOnOs(WINDOWS).

[loicmathieu]

@evanchooly there is no docker on Windows CI. That's why we don't use testcontainers for MongoDB tests but the testresource. But even the testresource didn't works very well on Windows due to some issue on flapdoodle side so we ends up disabling the test on Windows: @DisabledOnOs(WINDOWS).

But you didn't add new tests so I don't understand why you have this ...

[geoand]

But you didn't add new tests so I don't understand why you have this ...

Probably because:

            <plugin>
                <artifactId>maven-failsafe-plugin</artifactId>
                <configuration>
                    <skip>true</skip>
                </configuration>
            </plugin>

was removed

[evanchooly]

fixed the windows failure by disabling it via a profile when on windows. the last CI run was all green so I squashed the commits and force pushed. we should be all good to go now.

[famod]

It seems this PR has broken NamedMongoClientConfigTest and NamedReactiveMongoClientConfigTest on Windows. All current builds seem to fail because of this.

The failsafe-skip-profile won't work for those as both are run via surefire.

[geoand]

Yup, @evanchooly is looking into it