Add .enabled/.active configuration properties to Hibernate ORM, Reactive and Envers extensions

[yrodiere]

Fixes #17516, and goes a bit further.

In a previous PR (#26840), I reworked the Hibernate Search extension so that it exposes two configuration properties:

• quarkus.hibernate-search-orm.enabled, to enable/disable the extension a build time, for all persistence units. Setting it to false will disable almost all build steps of the extension. This is mostly useful for re-augmentation of Quarkus apps, to disable an extension that is not necessary in a given deployment.
• quarkus.hibernate-search-orm.active/quarkus.hibernate-search-orm."some-pu".active, to activate/deactivate the extension for a particular persistence unit. Setting it to false will prevent Hibernate Search from starting at runtime for the corresponding persistence unit. This is mostly useful when entities are annotated with Hibernate Search annotations (@Indexed) but for some reason one wants to disable Hibernate Search in a given persistence unit; that can happen e.g. when importing entity classes from a common company JAR, which is a surprisingly (and regrettably, if you ask me) common practice. Critically, this is also a runtime property, which I suppose can be useful for some exotic use cases.

I did look into making the .enabled property available on a per-persistence unit basis, but honestly, it's much more complicated, so I personally would avoid that until we have a convincing use case.

This PR adds similar configuration properties for other extensions:

• For Hibernate ORM and Hibernate Reactive:
  • quarkus.hibernate-orm.enabled
  • quarkus.hibernate-orm.active/quarkus.hibernate-orm."some-pu".active
• For Hibernate Envers:
  • quarkus.hibernate-envers.enabled
  • quarkus.hibernate-envers.active/quarkus.hibernate-envers."some-pu".active

In the case of Envers, unfortunately, .active is a build-time property. That's because Envers adds entities to the metamodel, and we cannot remove those at runtime (they are added during static init). Hopefully one day we'll be able to "veto" entities at runtime init through some SPI, but this SPI doesn't exist yet, so .active will have to remain a build-time property until then.

I noticed while working on the Envers extension that all configuration is global, with no way of customizing it on a per-persistence unit basis. I don't know if that's on purpose; maybe we should create another issue to address that?

[quarkus-bot]

/cc @Sanne, @gsmet

[gsmet]

We are sure that this will always be set properly? IIRC we ended up with injection because we had some race conditions. But it might have been with an old pattern and things might have changed.

[yrodiere]

I don't know about that race condition and I don't see any failing test, so I can't say...

What I can say:

• JPAConfigSupport was introduced to "make JPAConfig less brittle"; not sure if it was about an actual bug or design concerns (best practices).
• JPAConfigSupport initially contained more information than just persistence unit names; that is no longer the case.
• PersistenceUnitsHolder is initialized at static init:

  • quarkus/extensions/hibernate-orm/runtime/src/main/java/io/quarkus/hibernate/orm/runtime/HibernateOrmRecorder.java

    Lines 73 to 79 in aec43cd

    	return new BeanContainerListener() {
    	@Override
    	public void created(BeanContainer beanContainer) {
    	PersistenceUnitsHolder.initializeJpa(parsedPersistenceXmlDescriptors, scanner, additionalIntegrators,
    	proxyDefinitions);
    	}
    	};

• JPAConfig is supposedly only used at runtime; that makes sense since session factories are a runtime construct. Here are the only uses I found:

  • quarkus/extensions/hibernate-orm/runtime/src/main/java/io/quarkus/hibernate/orm/runtime/metrics/HibernateMetricsRecorder.java

    Lines 24 to 29 in bc4955b

    	/* RUNTIME_INIT for metrics */
    	public Consumer<MetricsFactory> consumeMetricsFactory() {
    	return new Consumer<MetricsFactory>() {
    	@Override
    	public void accept(MetricsFactory metricsFactory) {
    	JPAConfig jpaConfig = Arc.container().instance(JPAConfig.class).get();

  • quarkus/extensions/hibernate-orm/runtime/src/main/java/io/quarkus/hibernate/orm/runtime/HibernateOrmRecorder.java

    Lines 98 to 104 in e9b4dce

    	public Supplier<SessionFactory> sessionFactorySupplier(String persistenceUnitName) {
    	return new Supplier<SessionFactory>() {
    	@Override
    	public SessionFactory get() {
    	SessionFactory sessionFactory = Arc.container().instance(JPAConfig.class).get()
    	.getEntityManagerFactory(persistenceUnitName)
    	.unwrap(SessionFactory.class);

  • quarkus/extensions/hibernate-orm/runtime/src/main/java/io/quarkus/hibernate/orm/runtime/HibernateOrmRecorder.java

    Lines 103 to 105 in aec43cd

    	public void startAllPersistenceUnits(BeanContainer beanContainer) {
    	beanContainer.instance(JPAConfig.class).startAll();
    	}

  • quarkus/extensions/hibernate-orm/runtime/src/main/java/io/quarkus/hibernate/orm/runtime/TransactionSessions.java

    Lines 18 to 22 in 1aec4e3

    	@ApplicationScoped
    	public class TransactionSessions {
    	@Inject
    	JPAConfig jpaConfig;

• Tests pass 🤷

If for some reason tests start failing because the constructor of JPAConfig ends up being executed during static init (and before PersistenceUnitsHolder is initialized), we can make JPAConfig a synthetic bean and force runtime init. Or, worst case, we can make JPAConfig @ApplicationScoped, so that it's created on first use.

In fact, I can create a quick PR to make JPAConfig a synthetic bean right now. It seems more correct, regardless of whether it's necessary, because that bean is fundamentally a runtime bean. I'll open that PR soon.

[gsmet]

I added a question. If you're sure things are fine, you can merge it.

[yrodiere]

Merged, thanks! I'll submit another PR to make the JPAConfig change safer.

[yrodiere]

Actually, after a bit of digging, Singleton beans are initialized when they are first injected or retrieved programmatically, just like ApplicationScoped beans:

quarkus/independent-projects/arc/runtime/src/main/java/io/quarkus/arc/impl/SingletonContext.java

Line 8 in c4a5f99

class SingletonContext extends AbstractSharedContext {

quarkus/independent-projects/arc/runtime/src/main/java/io/quarkus/arc/impl/AbstractSharedContext.java

Lines 24 to 38 in 50f5d3d

	@Override
	public <T> T get(Contextual<T> contextual, CreationalContext<T> creationalContext) {
	Objects.requireNonNull(contextual, "Contextual must not be null");
	Objects.requireNonNull(creationalContext, "CreationalContext must not be null");
	InjectableBean<T> bean = (InjectableBean<T>) contextual;
	if (!Scopes.scopeMatches(this, bean)) {
	throw Scopes.scopeDoesNotMatchException(this, bean);
	}
	return (T) instances.computeIfAbsent(bean.getIdentifier(), new Supplier<ContextInstanceHandle<?>>() {
	@Override
	public ContextInstanceHandle<?> get() {
	return createInstanceHandle(bean, creationalContext);
	}
	}).get();
	}

So as long as we only use inject/retrieve JPAConfig at runtime, we should be safe. And if we start using injecting/retrieving it during static init, in particular before PersistenceUnitsHolder is initialized, we'll get a nice exception:

quarkus/extensions/hibernate-orm/runtime/src/main/java/io/quarkus/hibernate/orm/runtime/PersistenceUnitsHolder.java

Lines 83 to 87 in 0bc9711

	private static void checkJPAInitialization() {
	if (persistenceUnits == null) {
	throw new RuntimeException("JPA not initialized yet by Quarkus: this is likely a bug.");
	}
	}

Which is better (well, at least more specific) than what we'd get if we attempted to use a runtime-initialized, synthetic CDI bean:

quarkus/extensions/arc/deployment/src/main/java/io/quarkus/arc/deployment/SyntheticBeansProcessor.java

Lines 116 to 128 in 0cef176

	private String createMessage(String name, SyntheticBeanBuildItem bean) {
	StringBuilder builder = new StringBuilder();
	builder.append("Synthetic bean instance for ");
	builder.append(bean.configurator().getImplClazz());
	builder.append(" not initialized yet: ");
	builder.append(name);
	if (!bean.isStaticInit()) {
	builder.append("\n\t- a synthetic bean initialized during RUNTIME_INIT must not be accessed during STATIC_INIT");
	builder.append(
	"\n\t- RUNTIME_INIT build steps that require access to synthetic beans initialized during RUNTIME_INIT should consume the SyntheticBeansRuntimeInitBuildItem");
	}
	return builder.toString();
	}

So, I'll leave JPAConfig as it is now.