Subject:
Question about lifecycle constraint: Registering BeanDefinitionRegistryPostProcessor via ImportBeanDefinitionRegistrar
Body:
I have a question regarding the lifecycle constraint mentioned in the Spring ImportBeanDefinitionRegistrar documentation.
In its registerBeanDefinitions method Javadoc, it clearly states that "BeanDefinitionRegistryPostProcessor types may not be registered here, due to lifecycle constraints related to @configuration class processing".
However, I have observed a seemingly contradictory practice in the MyBatis-Spring integration (mybatis-spring package). The MapperScannerRegistrar class, which implements ImportBeanDefinitionRegistrar, registers a MapperScannerConfigurer. Notably, MapperScannerConfigurer itself implements the BeanDefinitionRegistryPostProcessor interface.
This appears to be a direct violation of the documented constraint. Could you please clarify if this is a known exception to the rule, or if there is a specific lifecycle nuance I am misunderstanding?
My current understanding is that MapperScannerRegistrar registers MapperScannerConfigurer as a standard bean definition. This allows Spring to detect and invoke it as a BeanDefinitionRegistryPostProcessor later in the refresh cycle, after ConfigurationClassPostProcessor has completed its work. This effectively bypasses the documented restriction.
Is my interpretation accurate? If so, I believe this could be a valuable clarification to add to the official documentation for ImportBeanDefinitionRegistrar to help developers understand this subtle but important pattern. Or is there a deeper architectural reason why this pattern is discouraged for general use, even if technically possible through this indirect registration?
Subject:
Question about lifecycle constraint: Registering BeanDefinitionRegistryPostProcessor via ImportBeanDefinitionRegistrar
Body:
I have a question regarding the lifecycle constraint mentioned in the Spring ImportBeanDefinitionRegistrar documentation.
In its registerBeanDefinitions method Javadoc, it clearly states that "BeanDefinitionRegistryPostProcessor types may not be registered here, due to lifecycle constraints related to @configuration class processing".
However, I have observed a seemingly contradictory practice in the MyBatis-Spring integration (mybatis-spring package). The MapperScannerRegistrar class, which implements ImportBeanDefinitionRegistrar, registers a MapperScannerConfigurer. Notably, MapperScannerConfigurer itself implements the BeanDefinitionRegistryPostProcessor interface.
This appears to be a direct violation of the documented constraint. Could you please clarify if this is a known exception to the rule, or if there is a specific lifecycle nuance I am misunderstanding?
My current understanding is that MapperScannerRegistrar registers MapperScannerConfigurer as a standard bean definition. This allows Spring to detect and invoke it as a BeanDefinitionRegistryPostProcessor later in the refresh cycle, after ConfigurationClassPostProcessor has completed its work. This effectively bypasses the documented restriction.
Is my interpretation accurate? If so, I believe this could be a valuable clarification to add to the official documentation for ImportBeanDefinitionRegistrar to help developers understand this subtle but important pattern. Or is there a deeper architectural reason why this pattern is discouraged for general use, even if technically possible through this indirect registration?