de.flapdoodle.embed.mongo: Unable to run Embedded MongoDB on Macbook Pro with M1 CPU (ARM architecture)
As title says - it looks similiar to issue #336.
Caused by: org.springframework.beans.BeanInstantiationException: Failed to instantiate [de.flapdoodle.embed.mongo.MongodExecutable]: Factory method 'embeddedMongoServer' threw exception; nested exception is java.lang.IllegalArgumentException: this version does not support 32Bit: Version{3.5.5}:OS_X:B32
at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:185)
at org.springframework.beans.factory.support.ConstructorResolver.instantiate(ConstructorResolver.java:652)
... 82 more
Caused by: java.lang.IllegalArgumentException: this version does not support 32Bit: Version{3.5.5}:OS_X:B32
at de.flapdoodle.embed.mongo.Paths.getBitSize(Paths.java:157)
at de.flapdoodle.embed.mongo.Paths.getPath(Paths.java:97)
at de.flapdoodle.embed.process.store.LocalArtifactStore.getArtifact(LocalArtifactStore.java:71)
at de.flapdoodle.embed.process.store.LocalArtifactStore.checkArtifact(LocalArtifactStore.java:38)
at de.flapdoodle.embed.process.store.ArtifactStore.checkDistribution(ArtifactStore.java:65)
at de.flapdoodle.embed.process.store.ExtractedArtifactStore.checkDistribution(ExtractedArtifactStore.java:60)
at de.flapdoodle.embed.process.runtime.Starter.prepare(Starter.java:52)
at de.flapdoodle.embed.process.runtime.Starter.prepare(Starter.java:45)
at org.springframework.boot.autoconfigure.mongo.embedded.EmbeddedMongoAutoConfiguration.embeddedMongoServer(EmbeddedMongoAutoConfiguration.java:113)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:154)
... 83 more
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 11
- Comments: 38 (19 by maintainers)
Commits related to this issue
- OK-316 korjaa mongo-yksikkötestit toimimaan arm maceissa Katso: https://github.com/flapdoodle-oss/de.flapdoodle.embed.mongo/issues/337 — committed to Opetushallitus/sijoittelu by deleted user a year ago
- OK-316 Korjattu mongo-yksikkötestit toimimaan arm maceissa Katso: https://github.com/flapdoodle-oss/de.flapdoodle.embed.mongo/issues/337 — committed to Opetushallitus/sijoittelu by deleted user a year ago
A dirty workaround for local development (don’t use it in prod environment) on your M1 mac you can add the following in the static block of your @SpringBootApplication
static { System.setProperty("os.arch", "i686_64"); }
@m-grzesiak @MatthewRyanRead @martin-g @jgriff now you can override platform detection with https://github.com/flapdoodle-oss/de.flapdoodle.os#run
@MatthewRyanRead hmm… seems a little bit more complicated: https://stackoverflow.com/questions/65259300/detect-apple-silicon-from-command-line … i must think about this a little bit.
@michaelmosmann yes, I believe the problem is really 2 fold.
linux/arm64/v8
).linux/arm64/v8
.So really, flapdoodle seems to fall back to the nearest cousin
ARM_64
/x86_64
Ubuntu.But since this isn’t the native platform for an M1 Mac, Rosetta 2 attempts to emulate it. And the flapdoodle launcher has apparently found one of the cracks in the emulation, and cannot find
/lib64/ld-linux-x86-64.so.2
.So as I mention in this related issue, we really need Mongo to support the
linux/arm64/v8
distribution and then for flapdoodle to recognize and use it.It is weird that native Groovy reports
x86_64
while native Javaaarch64
. I’d expect both to beaarch64
@jgriff … maybe we are looking at the wrong direction … the mongo version 3.4.23 is very old… so i think the case is just the other way… do you know if a process started in native mode can start an other process in emulation mode? So that the right x86-mongodb binary may work?
@MatthewRyanRead is correct:
My
JAVA_HOME
wasn’t explicitly set, so Groovy defaulted to my system JVM which was15
.I use
jenv
and currently have17
set globally. Butjenv
doesn’t exportJAVA_HOME
by default.So I just enabled the
export
plugin to exportJAVA_HOME
,and now Groovy reports the expected
aarch64
.But it’s at least worth noting/discovering that older JVMs don’t recognize
aarch64
.