Enhancement Description
The SpringComponentRegistry initializes in ordered steps: configuration enhancers are invoked first, and only afterwards are locally registered Axon components promoted to Spring bean definitions. When user code queries Configuration.getComponent(...) before that promotion has happened, the lookup falls through to beanFactory.getBean(type) and misses, even though the component is registered and would resolve fine moments later.
The most common trigger is a Spring @Bean method that injects AxonConfiguration (safe) and then queries it during bean construction (unsafe), for example to build a PersistentStreamEventSource. Because MessageHandlerConfigurer forces such beans during the enhancer phase, the failure surfaces as a misleading Spring report blaming the outermost injection point and the deepest missing type, for example:
Parameter 0 of method processorModuleFactory in
org.axonframework.extension.springboot.autoconfig.EventProcessingAutoConfiguration
required a bean of type 'io.axoniq.framework.axonserver.connector.api.AxonServerConnectionManager'
Nothing in this message points at the actual mistake: querying the configuration during bean construction. A fail-fast guard in SpringComponentRegistry.getComponent (and getOptionalComponent) that detects lookups before component promotion and throws a descriptive exception would turn a confusing boot failure into an actionable one.
Current Behaviour
getComponent(...) invoked during the enhancer phase silently misses components that are registered but not yet promoted.- The resulting failure is a
NoSuchBeanDefinitionException attributed to an unrelated injection point, hiding the actual cause.
Wanted Behaviour
- While
SpringComponentRegistry.initialize() has not yet promoted local components to bean definitions, component lookups from user code fail fast with a message along the lines of: "Axon components are not available while the configuration is being initialized. Defer this lookup, for example into a component builder, so it runs after initialization."
- Framework-internal lookups that legitimately run during initialization must remain unaffected.
Possible Workarounds
- Hold the injected
AxonConfiguration and defer all getComponent(...) calls into lazily evaluated callbacks, such as a ComponentBuilder, which run after initialization completes.
Related: #4721
Enhancement Description
The
SpringComponentRegistryinitializes in ordered steps: configuration enhancers are invoked first, and only afterwards are locally registered Axon components promoted to Spring bean definitions. When user code queriesConfiguration.getComponent(...)before that promotion has happened, the lookup falls through tobeanFactory.getBean(type)and misses, even though the component is registered and would resolve fine moments later.The most common trigger is a Spring
@Beanmethod that injectsAxonConfiguration(safe) and then queries it during bean construction (unsafe), for example to build aPersistentStreamEventSource. BecauseMessageHandlerConfigurerforces such beans during the enhancer phase, the failure surfaces as a misleading Spring report blaming the outermost injection point and the deepest missing type, for example:Nothing in this message points at the actual mistake: querying the configuration during bean construction. A fail-fast guard in
SpringComponentRegistry.getComponent(andgetOptionalComponent) that detects lookups before component promotion and throws a descriptive exception would turn a confusing boot failure into an actionable one.Current Behaviour
getComponent(...)invoked during the enhancer phase silently misses components that are registered but not yet promoted.NoSuchBeanDefinitionExceptionattributed to an unrelated injection point, hiding the actual cause.Wanted Behaviour
SpringComponentRegistry.initialize()has not yet promoted local components to bean definitions, component lookups from user code fail fast with a message along the lines of: "Axon components are not available while the configuration is being initialized. Defer this lookup, for example into a component builder, so it runs after initialization."Possible Workarounds
AxonConfigurationand defer allgetComponent(...)calls into lazily evaluated callbacks, such as aComponentBuilder, which run after initialization completes.Related: #4721