hibernate/hibernate-orm · error · StrategySelectionException

Default resolver threw exception

Error message

Default resolver threw exception

What it means

When resolveStrategy(strategy, reference, defaultResolver, creator) is called with a null strategy reference, it invokes the supplied defaultResolver callable; any exception it throws is wrapped as StrategySelectionException 'Default resolver threw exception'. The informative failure is in the cause chain: the default-resolution logic itself - for dialect resolution, typically automatic detection from the JDBC connection metadata.

Source

Thrown at hibernate-core/src/main/java/org/hibernate/boot/registry/selector/internal/StrategySelectorImpl.java:166

				implementors.add( registration.asSubclass( strategy ) );
			}
			return implementors;
		}
	}

	@SuppressWarnings("unchecked")
	@Override
	public <T> T resolveStrategy(
			Class<T> strategy,
			Object strategyReference,
			Callable<T> defaultResolver,
			StrategyCreator<T> creator) {
		if ( strategyReference == null ) {
			try {
				return defaultResolver.call();
			}
			catch (Exception e) {
				throw new StrategySelectionException( "Default resolver threw exception", e );
			}
		}
		else if ( strategy.isInstance( strategyReference ) ) {
			return strategy.cast( strategyReference );
		}
		else {
			final var implementationClass =
					strategyReference instanceof Class
							? (Class<? extends T>) strategyReference
							: selectStrategyImplementor( strategy, strategyReference.toString() );
			try {
				return creator.create( implementationClass );
			}
			catch (Exception e) {
				throw new StrategySelectionException(
						String.format( "Could not instantiate named strategy class [%s]",
								implementationClass.getName() ),
						e

View on GitHub (pinned to fad1729dce)

Solutions

1. Set the strategy explicitly (hibernate.dialect=org.hibernate.dialect.PostgreSQLDialect) to bypass default resolution entirely
2. Inspect the cause of the StrategySelectionException - it holds the real error from the resolver; fix that underlying issue
3. Ensure the database connection works and JDBC metadata is readable before building the factory (e.g., wait-for-it in CI)

Example fix

// before
<property name="hibernate.dialect" value=""/> <!-- or absent; auto-detect fails -->

// after
<property name="hibernate.dialect" value="org.hibernate.dialect.PostgreSQLDialect"/>

// Fail fast on unusable defaults: set the dialect explicitly before boot
if (!config.containsKey("hibernate.dialect") && !isDatabaseReachable(jdbcUrl)) {
    throw new IllegalStateException(
        "No hibernate.dialect set and the database is not reachable for auto-detection");
}

try {
    return strategySelector.resolveStrategy(Dialect.class, null, defaultResolver, creator);
} catch (StrategySelectionException e) {
    // the cause holds the real error from the default resolver (often JDBC metadata access)
    throw new ConfigurationException("Default dialect resolution failed", e.getCause());
}

When it happens

Trigger: Omitting a strategy setting (e.g., no hibernate.dialect) so the default resolver runs, while the default logic fails - database metadata unreadable, unknown database or version, JDBC connection problems - during SessionFactory/EntityManagerFactory build.

Common situations: Boot without hibernate.dialect against an unsupported, unreachable, or not-yet-ready database; custom default-resolver lambdas that throw (NPE on missing config); CI pipelines starting the app before the database container is up.

Related errors

• Unable to resolve name [{}] as strategy [{}]
• Configuration property hibernate.jdbc.time_zone value [{}] i
• Cannot instantiate the class [{}] because it does not have a
• Unknown TcclLookupPrecedence - {}
• Implementation class [{}] does not implement strategy interf

AI-assisted analysis of hibernate/hibernate-orm@fad1729dce (2026-08-22). Data as JSON: /api/errors/ce3359be794d8453. Report an issue: GitHub.