Allow usage of BeanNameGenerator in ImportBeanDefinitionRegistrars

[odrotbohm]

A BeanNameGenerator can be configured for usage in component scanning configuration classes. That support allows custom annotation based activation of functionality via annotations importing an ImportBeanDefinitionRegistrar. Its primary callback method unfortunately currently doesn't provide access to the BeanNameGenerator potentially provided so that a customization of that generator cannot be considered for components registered via the registrar.

It would be nice, if there was a way to consume the BeanNameGenerator to allow components being registered to follow the configured naming strategy.

[odrotbohm]

It looks like we're getting the generator that's used for the configuration class scanning, not the one used to name scanned components. I've put in check for the enclosing class of the provided instance to only opt in using it if it's not ConfigurationClassPostProcessor. Is there maybe a chance we can expose the default one used in a slightly more convenient way (a constant in ConfigurationClassPostProcessor maybe)?

[sbrannen]

Reopening to consider comments from @odrotbohm.

[jhoeller]

@odrotbohm So you'd simply like to be able to ignore the default import bean name generator more easily, e.g. by comparing it to a constant on ConfigurationClassPostProcessor, proceeding with an externally configured BeanNameGenerator only?

[odrotbohm]

Yes. Fundamentally, we're scanning for components ourselves. I.e. for us, the bean name generator used to name scanned components would be the more appropriate one. It looks like the user override is trumping both default variants Spring Framework uses internally.

If that stays the same, I'm fine with just using the one handed down, if it's not the default one. To detect that, something to easily compare the handed down instance to would allow us to remove the rather brittle check of inspecting the surrounding class.

[jhoeller]

Alright, I've added an IMPORT_BEAN_NAME_GENERATOR constant on ConfigurationClassPostProcessor, along with a common AnnotationBeanNameGenerator.INSTANCE that serves as the default for component scanning purposes.

[odrotbohm]

I hate to bring this up again but we face the same issue with the XML flavor as the BeanDefinitionReader exposes an instance of DefaultBeanNameGenerator. If that in use, we have to fall back to an AnnotationBeanNameGenerator. I fall back to our default value if the handed in instance is a exactly DefaultBeanNameGenerator assuming that all customizations would have to either provide a subtype or a completely different implementation of BeanNameGenerator.

However, ultimately we're facing the same slightly brittle situation of detecting the default.

[jhoeller]

Hmm, in line with the common instance constants, DefaultBeanNameGenerator should have one too... So if we introduce an INSTANCE constant there as well, used for defaulting like we do for AnnotationBeanNameGenerator already, would that be sufficient for your purposes?

[odrotbohm]

Yes, I think so.