In order to provide the possibility for registering RuntimeHints
, the proposal is to introduce a RuntimeHintsRegistrar
abstraction designed to address the same needs than BeanFactoryNativeConfigurationProcessor
and BeanNativeConfigurationProcessor
in Spring Native. It could even be used initially to register static hints as done with @NativeHint
annotations.
package org.springframework.beans.factory.hint;
public interface RuntimeHintsRegistrar {
void registerHints(RuntimeHints hints, ListableBeanFactory beanFactory);
default void ifPresent(String className, Runnable runnable) {
if (ClassUtils.isPresent(className, null)) {
runnable.run();
}
}
}
The registerIfPresent
method is designed to provide a more discoverable mechanism to prevent ClassNotFoundException
errors than inner classes.
Since they are designed to be used only AOT, spring.factories
is not a good fit here, so implementations could be registered via a META-INF/spring/org.springframework.beans.factory.hint.RuntimeHintsRegistrar.imports
file with the same format than org.springframework.boot.autoconfigure.AutoConfiguration.imports
.
Comment From: snicoll
Since they are designed to be used only AOT, spring.factories is not a good fit here
I don't necessarily disagree but it is disruptive to introduce another mechanism for that reason alone. There are many other concepts in the core container that behave differently when AOT is involved. For instance, we could imagine a class-level annotation on the type that provides some opt-in metadata that the transformer can use to ignore those entries.
I am not huge fan of the factory.hint
package. Perhaps it is a smell that something named RuntimeHintsRegistrar
is taking the bean factory as an argument?
cc @philwebb as I know he's been brainstorming on this topic as well.