-
Notifications
You must be signed in to change notification settings - Fork 1
Troubleshooting
The app is not code-signed with an Apple Developer certificate. To open it:
Option 1: Right-click the app → Open → click Open in the dialog.
Option 2: Run in Terminal:
xattr -cr /Applications/Launcher.appThe administrator is a JavaFX application, so Launcher must start it with a JavaFX-enabled JDK. A plain OpenJDK will start and then fail with "JavaFX runtime components are missing".
Launcher does not auto-detect or guess a JDK. It resolves Java in this order:
- The connection's Java Home field, if set (
<Java Home>/bin/java) - Otherwise
javaon the systemPATH
Before any download, Launcher runs a fast java -version check. If that fails, the launch is aborted with:
Java (with JavaFX) not found ... Set Java Home to a JavaFX-enabled JDK, or put one on PATH.
To fix it, install a JavaFX-enabled JDK and either set the connection's Java Home to it or put its bin directory on PATH.
Note: the java -version check only confirms a Java runtime is launchable, not that it includes JavaFX. If that check passes but the administrator window never appears and the console shows "JavaFX runtime components are missing", the resolved Java lacks JavaFX — switch Java Home to a JavaFX-enabled JDK.
- Check the connection address is correct (must include protocol and port, e.g.,
https://myserver:8443) - Verify the server is reachable (check the status indicator on the main screen)
- Make sure the connection's Java points to a JavaFX-enabled JDK (see Java Not Found)
- Enable Show console in the connection options to see the administrator's stdout and stderr in a native console window
Launcher pins each connection's TLS certificate on first use (trust-on-first-use). The trusted fingerprint is stored per connection as pinnedCertSha256 inside ~/.launcher/launcher-data.json — there is no separate trust-store file.
First connection — Launcher captures the server's leaf certificate and shows its SHA-256 fingerprint in a "Trust this server's certificate?" prompt. Verify the fingerprint with the server operator out-of-band before trusting; clicking Trust certificate saves it as the pin.
Certificate changed — On a later launch, if the server presents a different certificate you'll see a "This server's certificate changed" warning showing both the new fingerprint and the one you previously trusted. This is expected after a legitimate certificate renewal or re-issue. If you did not expect it, stop — a changed certificate can indicate an interception attempt. Only click Trust new certificate after confirming the change with the operator; doing so replaces the stored pin.
The status check makes a quick HTTP GET to /api/system/info with a 2 second connect timeout. Common causes for unavailable status:
- Server is down or unreachable
- Firewall blocking the connection
- Incorrect address (wrong port, missing
https://) - Connection timed out (2 second limit)
The status probe accepts self-signed certificates and ignores hostname mismatches, so it is purely a reachability check. It does not verify the certificate pin — a green dot means the server answered, not that its certificate matches what you trusted. The pin is checked separately at launch time.
If a launch stops with a warning that the cached jars for an engine type and version don't match what the server sent, two of your connections are almost certainly sharing one cache directory while pointing at different engines.
The JAR cache is keyed by engine type + version, and a given engine release always ships identical jars. The usual cause is a connection left on the default Open Integration Engine engine type that actually points at a different engine (for example, Mirth) at the same version number, so both connections resolve to the same cache/{engine-type}/{version}/ directory.
To fix it, open the connection editor and set the Engine Type field to a distinct value for each engine, so they no longer collide. You can also click continue to overwrite the cache for the current launch, but the two connections will keep fighting over the shared directory until their engine types differ.
On Launcher versions before 2.2.0, launching a Mirth 4.7.x administrator could fail at login with:
java.lang.IllegalAccessError: ... org.mozilla.javascript.NativeDate
Mirth 4.7.x ships patched Rhino overlay jars (*-mc-modifications.jar) that must load ahead of the stock Rhino jar on the classpath. Older Launcher builds sorted the jars alphabetically, which loaded the stock jar first and triggered the access error. This is fixed in 2.2.0, which preserves the JNLP-declared jar order. If you still hit it, update to 2.2.0 or later. Clearing the affected cache (rm -rf ~/.launcher/cache) forces a clean re-download in the correct order on the next launch.
Launcher automatically migrates data from previous versions on first run:
| Version | Data Location |
|---|---|
| < 0.2.0 (Catapult) | ~/catapult-data.json |
| 0.2.0 - 1.x (Ballista) | ~/.ballista/ballista-data.json |
| 2.x+ (Launcher) | ~/.launcher/launcher-data.json |
Migration is automatic and non-destructive (moves the legacy file only when no current file exists).
Install create-dmg:
brew install create-dmgThe .app builds successfully even without this — only the DMG packaging step requires it.
Launcher builds native-tls with vendored OpenSSL, which needs an OpenSSL build toolchain — Perl on all platforms, plus NASM on Windows. See Building from Source for setup instructions.
Make sure you are running from the repo root, not from src-tauri/:
# Correct
npm run tauri build
# Or for Rust-only checks
cargo check --manifest-path src-tauri/Cargo.tomlTo start fresh, remove the data directory:
rm -rf ~/.launcherThis removes all connections (including their trusted certificate pins), cached JARs, and logs. Launcher will recreate the directory on next launch.