Skip to content

Validate mirth.properties at startup and refuse to run on any invalid value #413

Description

@pacmano1

mirth.properties values are read ad-hoc across the codebase with inline defaults, and validation is inconsistent: some settings fail fast, some crash, some silently coerce. On adjacent lines of Mirth.run(), http.port = banana throws an uncaught ConversionException via isUsingHttp()'s default-less getInt and the server thread dies with a stack trace, while https.port = banana right next to it refuses to start cleanly with "port is invalid" (testPort). Booleans coerce to false (Boolean.parseBoolean), https.*.protocols passes through unvalidated, while a few settings do have ad-hoc guards (the DH key-size clamp, password requirements). Same class of mistake, different outcomes.

Target the model nginx (nginx -t), Apache (configtest), haproxy (-c), and sshd (-t) use: one validation pass over the whole merged config (base + conf/mirth.properties.d drop-ins, #405) at startup, refuse to run on any invalid value, with a clear message naming the property and the reason. Never start on a config that doesn't fully parse.

Why this is architectural, not a patch:

  • No config schema exists. nginx validates everything because its parser is the schema; every directive has a known type and constraints. mirth.properties has no central registry of valid key -> type -> constraints -> required. Step one is building that registry.
  • Validate the merged config against the registry at startup; fail closed with a per-property message on any type/range/enum violation.
  • Mistyped keys can't be caught the way nginx catches an unknown directive: htp.port = 8080 silently leaves http.port at its default. The registry would need to flag unknown keys (warn or fail) - a design call.
  • Offer a check mode (-t-style "validate and exit") so operators can test before a restart.

Context: came up during #405, which added fail-closed handling for unreadable/malformed drop-in files. This covers invalid values in readable files.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions