Read env vars for server name and env name

[rogin]

Written to fix my own request here. NextGen merged it into their 4.6.0 release, so it's missing here.

Original test notes written here:

Used a freshly built server under /server/setup.

Start server with java -jar .\mirth-server-launcher.jar, and bring the server down after each test.

Test 1: No envvars set. Start server. Complete the admin change password modal. Validate values are blank in UI.
Test 2: set envvar MC_SERVER_NAME = 'Staging'. Start server. Validate its value in UI.
Test 3: set envvar MC_ENV_NAME = 'Sys-001'. Start server. Validate both values in UI.
Test 4: set envvar MC_SERVER_NAME = 'Prod', MC_ENV_NAME = 'Sys-002'. Start server. Validate both values in UI.
Test 5: Unset envvars MC_SERVER_NAME and MC_ENV_NAME. Start server. Validate both values in UI are same used in test 4 (as they've been stored in DB).

[jonbartels]

This PR eliminates the need for booter mcgooter

[tonygermano]

question: would the configuration controller be a more appropriate place for this functionality?

Or is there a reason it must be in Mirth.java?

[rogin]

question: would the configuration controller be a more appropriate place for this functionality?

Or is there a reason it must be in Mirth.java?

Yep, a single call to the controller is likely cleaner.

[github-actions]

Test Results

  105 files  ±0    202 suites  ±0   6m 55s ⏱️ + 1m 8s
  633 tests ±0    633 ✅ ±0  0 💤 ±0  0 ❌ ±0 
1 266 runs  ±0  1 266 ✅ ±0  0 💤 ±0  0 ❌ ±0 

Results for commit f536fec. ± Comparison against base commit 7723b34.

[Copilot]

Pull request overview

Adds support for populating the server name and environment name from environment variables during server startup, aligning this codebase with the behavior present in NextGen’s 4.6.0 release.

Changes:

• Introduces ConfigurationController.updateServerSettingsFromEnvironment() and implements it in DefaultConfigurationController.
• Reads MC_SERVER_NAME / MC_ENV_NAME and persists them into server settings on startup (when provided).
• Invokes the new configuration update hook during Mirth.startup().

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 5 comments.

File	Description
server/src/com/mirth/connect/server/controllers/DefaultConfigurationController.java	Implements env-var read + server settings update logic.
server/src/com/mirth/connect/server/controllers/ConfigurationController.java	Adds new controller method for env-driven settings update.
server/src/com/mirth/connect/server/Mirth.java	Calls the new update hook during startup before starting the web server.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Javadoc is a bit misleading here: this method reads environment variables, not properties. Consider updating @return to describe the environment variable’s value (or Optional empty) to avoid confusion.

Suggested change

	* @return the property's value
	* @return an {@link Optional} containing the trimmed environment variable value if present and non-blank;
	* otherwise {@link Optional#empty()}

[Copilot]

Adding a new abstract method here is a binary-breaking change for any extension-provided ConfigurationController. DefaultConfigurationController.create() can load a custom controller via ExtensionLoader, and if that implementation was compiled against an older version it won’t implement this method, leading to AbstractMethodError when the server calls it during startup. Prefer making this a concrete no-op method (overrideable) to preserve backward compatibility for extensions.

Suggested change

	*/
	public abstract void updateServerSettingsFromEnvironment();
	* <p>
	* Default implementation is a no-op to preserve backward compatibility for
	* existing ConfigurationController implementations.
	*/
	public void updateServerSettingsFromEnvironment() {
	// No-op by default.
	}

[Copilot]

This startup call can throw AbstractMethodError at runtime if an extension supplies a custom ConfigurationController compiled against an older version (missing updateServerSettingsFromEnvironment). Either ensure the base class provides a default implementation, or guard this call (e.g., catch AbstractMethodError) so third-party controllers don’t prevent server startup.

Suggested change

	configurationController.updateServerSettingsFromEnvironment();
	try {
	configurationController.updateServerSettingsFromEnvironment();
	} catch (AbstractMethodError e) {
	logger.warn("ConfigurationController implementation does not support updateServerSettingsFromEnvironment; skipping environment-based server settings update for compatibility.", e);
	}

[Copilot]

updateServerSettingsFromEnvironment() currently calls getServerSettings() + setServerSettings(). setServerSettings() persists all core properties and saveProperty() may vacuum the configuration table each time, which can add a lot of DB writes/locks on every startup whenever either env var is set. Consider updating only the specific properties (environment.name and server.name) instead of calling setServerSettings(serverSettings).

[Copilot]

This new env-var-driven startup behavior isn’t covered by automated tests. Since server/test already has DefaultConfigurationController tests, please add tests that verify: (1) when env vars are absent/blank, DB values aren’t overwritten; (2) when present, the correct properties are saved. To make this testable without relying on mutating System.getenv, consider extracting env access behind an overrideable method or injectable supplier.