This is related to flapdoodle-oss/de.flapdoodle.embed.mongo/issues/223
Mentioning @snicoll, @wilkinsona as they seem to be most related to the affected features code.
application.yaml:spring:
mongodb:
embedded:
version: 3.6.3
While using the application.yaml described above, I was not able to use the embedded MongoDB. My integration tests failed with:
o.s.b.a.mongo.embedded.EmbeddedMongo : Error parsing command line: unrecognised option '--nohttpinterface'
o.s.b.a.mongo.embedded.EmbeddedMongo : try '/tmp/extract-5b9d0a8e-f9c7-4c8e-8aec-bf8f1e6b6cbcextractmongod --help' for more information
d.f.e.process.runtime.AbstractProcess : failed to call onAfterProcessStart()
After reporting the bug at upstream, I digged into the auto configuration found at spring-boot/spring-boot-project/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/mongo/embedded/EmbeddedMongoAutoConfiguration.java.
As @Loki-Afro suggested, the custom ToStringFriendlyFeatureAwareVersion is not respecting this breaking change in the upstream MongoDB binaries, as it does not add the Feature NO_HTTP_INTERFACE_ARG by itself. (compare to Version.java#L207 at Flapdoodle)
After changing my application.yaml to
spring:
mongodb:
embedded:
version: 3.6.3
features: sync_delay,no_http_interface_arg
my tests start working again. Adding no_http_interface_arg enables the "anti-feature" mentioned by @Loki-Afro, see also de.flapdoodle.embed.mongo/src/main/java/de/flapdoodle/embed/mongo/distribution/Feature.java
Please let me know if I shall create a fix plus test for this and open a PR or if you fix it yourself.
Thanks in advance!
if I (member of flapdoodle embed mongo) can support here somehow, just let me know ;)
@poikilotherm Thanks for the detailed analysis. I've targeted this to the 2.0.x backlog. If you do have any time to craft a PR that would be most welcome.
Hi @philwebb,
while sorting out ways to resolve this issue, I stumbled over the Javadoc of ToStringFriendlyFeatureAwareVersion.
/**
* A workaround for the lack of a {@code toString} implementation on
* {@code GenericFeatureAwareVersion}.
*/
The Javadoc states the custom class was used because there has been no toString(), but this seems to be present nowadays.
Would you feel comfortable replacing this entire (IMHO error-prone) construct using the upstream Versions.java instead or in combination to retain backward compatibility?
The helper-class has been introduced three years ago in 2c81907d5, things seem to have changed now. As this is Spring Boot v2.0.0, maybe it would be ok to make such a huge and possibly breaking change?
@Loki-Afro any thoughts on this?
Cheers and happy easter!
Poikilotherm
@poikilotherm It generally looks like `Versions might be a good thing to use if there's an exact match _and_ there are no feature properties defined.
I'm thinking we should probably change EmbeddedMongoProperties so that features is null. Then we could consider null to mean, use the defaults for that version. In the auto-configuration, if features is null we can iterate over the Version enum values to see if we can find a matching version. If we can we use the features from it.
The two things I'd like to keep if possible are:
I think GenericFeatureAwareVersion still doesn't have a toString so I guess our ToStringFriendlyFeatureAwareVersion needs to remain.
I've raised https://github.com/flapdoodle-oss/de.flapdoodle.embed.mongo/issues/240 to see if a toString can be added to GenericFeatureAwareVersion.
The toString has been added.
I think we may just need to backport a portion of this change.
On second look, I think the Embedded Mongo change is only in 2.1.0+ so we may have already done all we can here.
Closing per comment above.
Most helpful comment
I've raised https://github.com/flapdoodle-oss/de.flapdoodle.embed.mongo/issues/240 to see if a
toStringcan be added toGenericFeatureAwareVersion.