UpgradeInitializer halts servlet container

[ppkarwasz]

Current Behavior

UpgradeInitializer immediately terminates the entire Servlet Container if the connection to the database fails, by using Runtime.halt():

dependency-track/src/main/java/org/dependencytrack/upgrade/UpgradeInitializer.java

Lines 63 to 79 in ba0f375

	try (final UpgradeMetaProcessor ump = new UpgradeMetaProcessor()) {
	final VersionComparator currentVersion = ump.getSchemaVersion();
	if (currentVersion != null && currentVersion.isOlderThan(new VersionComparator("4.0.0"))) {
	LOGGER.error("Unable to upgrade Dependency-Track versions prior to v4.0.0. Please refer to documentation for migration details. Halting.");
	ump.close();
	Runtime.getRuntime().halt(-1);
	}
	ServiceLoader.load(PreUpgradeHook.class).stream()
	.map(ServiceLoader.Provider::get)
	.sorted(Comparator.comparingInt(PreUpgradeHook::priority))
	.filter(hook -> hook.shouldExecute(ump))
	.forEach(preUpgradeHooks::add);
	} catch (UpgradeException e) {
	LOGGER.error("An error occurred determining database schema version. Unable to continue.", e);
	Runtime.getRuntime().halt(-1);
	}

Steps to Reproduce

1. Modify application.properties with an error in the database credentials.
2. Deploy DependencyTrack to a Servlet Container.
3. The Servlet Container will crash immediately.

Expected Behavior

I would expect UpgradeInitializer to throw an exception that will stop DependencyTrack from starting, but leave the Servlet Container running.

Dependency-Track Version

4.12.6

Dependency-Track Distribution

Executable WAR

Database Server

N/A

Database Server Version

15

Browser

N/A

Checklist

• I have read and understand the contributing guidelines
• I have checked the existing issues for whether this defect was already reported

[nscuro]

Hmmm... I'm wondering, since DT is distributed as self-contained JAR file, what's the benefit of keeping the servlet container running if the application failed to start?

[ppkarwasz]

@nscuro,

I actually run it on a standalone Tomcat server in my dev environment.

In general it should be enough to throw an unchecked dependency to stop the embedded container from starting. This is what the other ServletContainerListeners are doing:

dependency-track/src/main/java/org/dependencytrack/RequirementsVerifier.java

Lines 58 to 68 in c3ece09

	if (Runtime.getRuntime().availableProcessors() < 2) {
	if (systemRequirementCheckEnabled) {
	setFailedValidation(true);
	final String message = "Dependency-Track requires a minimum of 2 CPU cores. Cannot continue. To fix, specify -Xmx4G (or higher) when executing Java.";
	LOGGER.error(message);
	throw new RequirementsException(message);
	} else {
	final String message = "Dependency-Track requires a minimum of 2 CPU cores. We highly recommand to use 2 CPU cores. Dependency-Track will continue to start, but may not function properly. https://docs.dependencytrack.org/getting-started/deploy-docker/#container-requirements-api-server";
	LOGGER.warn(message);
	}
	}