Skip to content

Add engine type dropdown, simplify cache and download pipeline#1

Open
pacmano1 wants to merge 7 commits into
masterfrom
engine-type-cache-simplify
Open

Add engine type dropdown, simplify cache and download pipeline#1
pacmano1 wants to merge 7 commits into
masterfrom
engine-type-cache-simplify

Conversation

@pacmano1
Copy link
Copy Markdown
Owner

Summary

  • Adds configurable "Engine Type" dropdown to server config dialog (default: Open Integration Engine) with insertable options, replacing auto-detection from /api endpoint
  • Splits JAR cache into core/ and extensions/{name}/ subdirectories, always re-fetching extension JNLPs to detect server-side updates via SHA-256 checksums
  • Removes CMS/PKCS#7 signature verification, cert trust flow, and related code (verify.rs, errors.rs, TrustCertModal) - relies on TLS like other launchers
  • Simplifies downloads to serial with HTTP keep-alive connection reuse, fixing a bug where all JARs were re-downloaded when the server provided no sha256 attributes
  • Persists search filter in localStorage so it survives navigation

Net: -1,174 lines deleted, +178 added.

Test plan

  • Create new connection - verify Engine Type dropdown defaults to "Open Integration Engine"
  • Add custom engine type, save, reopen - verify it persists and appears in dropdown
  • First launch downloads all JARs into core/ and extensions/ subdirectories
  • Second launch skips downloads (cache hit)
  • Update an extension on server, relaunch - verify changed extension JARs re-download
  • "Do not cache" option still wipes and re-downloads each launch
  • Search filter persists after editing a connection and returning to main screen
  • Test on Windows and macOS

- Add configurable engine type dropdown to server config (default: Open Integration Engine)
  with insertable options, used as vendor component of cache path
- Remove auto-detection of vendor from /api endpoint
- Split cache into core/ and extensions/{name}/ subdirectories
- Always re-fetch extension JNLPs to detect updated JARs via checksums
- Remove CMS/PKCS#7 signature verification (trust TLS like other launchers)
- Remove verify.rs, errors.rs, TrustCertModal, cert trust flow
- Remove cert store and trusted certs management from ConnectionStore
- Switch from parallel threaded downloads to serial with connection reuse
- Re-enable HTTP connection pooling (keep-alive)
- Fix cache bug: don't re-download JARs when server provides no sha256
- Persist search filter in localStorage across navigation
- Remove dead fields: icon, verify, url from data models
- Remove unused deps: openssl, openssl-probe, asn1-rs, zip, hex, schannel
- Replace openssl::base64 with base64 crate
- Replace println! with log macros (info!, warn!) throughout
- Replace hand-rolled JSON in to_json_array_string with serde_json
- Introduce LoadConfig struct to replace 8-parameter load() function
- Merge collect_jar_tasks and collect_extension_jar_tasks into one function
- Simplify get_node, get_client_args, get_j2ses, normalize_url
- Fix import() to hold mutex lock once for all inserts
- Simplify write_connections_to_disk to use File::create
- Remove redundant sanitize_vm_args prefixes
- Remove legacy trusted-certs migration (cert system removed)
- Remove #[allow(dead_code)] suppression
- Use javaw instead of java on Windows to avoid cmd.exe flash
- Remove CREATE_NO_WINDOW flags (javaw handles this natively)
- Add -Djava.awt.headless=false to console process
- Pipe stderr from target process so console shows all output
The Mar 21 fix swapped java to javaw to suppress the cmd.exe flash, but
javaw is a GUI-subsystem launcher that leaves stdin/stdout/stderr handles
invalid. JavaConsoleDialog reads stdin to display piped target output, so
it would open the dialog and immediately fail with "The handle is invalid."

Reverts to java for both spawned processes and restores CREATE_NO_WINDOW
on Windows so the cmd window is suppressed without losing valid handles.
Confirmed against BridgeLink-launcher which uses java.exe and the same
JavaConsoleDialog class.

Keeps the -Djava.awt.headless=false hint and the target stderr drain
thread from the Mar 21 commit.
Rust's Command defaults standard streams to inherited from parent, while
Java's ProcessBuilder defaults to piped. Tauri parent has no valid
console handles on Windows, so the inherited stdout/stderr were invalid
and JavaConsoleDialog crashed on its first write with "The handle is
invalid."

BridgeLink-launcher works because Java's defaults give it valid pipes
for free. We need to set them explicitly.
Stdio::null fix for stdout/stderr did not resolve the Windows console
launch failure. Switch console stderr to piped and drain it into
~/.launcher/logs/{conn_id}-console.err.log so we can see the actual
Java exception when it dies.

Stdout stays null since the dialog isn't expected to write there;
errors normally go to stderr.
Reverts webstart.rs to the b00b432 state, undoing 85816ca, 689e5aa,
4a4d3e6, and b5a561c. All four were attempts to fix or diagnose the
console dialog failing to open on Windows; none worked.

Console behavior on this branch now matches master (broken on Windows,
unchanged on macOS/Linux). Plan is to replace the Java JavaConsoleDialog
with a native Tauri/Vue console window in a follow-up PR.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant