Overridden bean definitions may cause incorrect bean condition evaluation due to stale information being held by BeanTypeRegistry

[prasenjit-net]

I have an interface AuditEventRepository in my project which is definitely not same as org.springframework.boot.actuate.audit.AuditEventRepository and also has a different purpose. but this is clashing with the bean declared in org.springframework.boot.actuate.autoconfigure.audit.AuditEventsEndpointAutoConfiguration#auditEventsEndpoint

@Bean
@ConditionalOnMissingBean
@ConditionalOnBean(AuditEventRepository.class)
@ConditionalOnEnabledEndpoint
public AuditEventsEndpoint auditEventsEndpoint(
		AuditEventRepository auditEventRepository) {
	return new AuditEventsEndpoint(auditEventRepository);
}

Reproduction step:
Have a bean with class simple name AuditEventRepository.

[philwebb]

We perhaps should try to find a way to make the names of our auto-configured beans more unique but that will need some thought on our part. For now, I'd suggest using naming your AuditEventRepository bean differently. You can change the bean name without changing the class name by using the value attribute of @Component.

[prasenjit-net]

Hi, @philwebb does @ConditionalOnBean searches by bean name? Shouldn't it search with the 'type'?

[philwebb]

It searches by type. What's the actual problem that you get? Can you attach a stack trace?

[prasenjit-net]

***************************
APPLICATION FAILED TO START
***************************

Description:

Parameter 0 of method auditEventsEndpoint in org.springframework.boot.actuate.autoconfigure.audit.AuditEventsEndpointAutoConfiguration required a bean of type 'org.springframework.boot.actuate.audit.AuditEventRepository' that could not be found.


Action:

Consider defining a bean of type 'org.springframework.boot.actuate.audit.AuditEventRepository' in your configuration.

Disconnected from the target VM, address: '127.0.0.1:63630', transport: 'socket'

Process finished with exit code 0

[prasenjit-net]

This above method has a condition @ConditionalOnBean(AuditEventRepository.class) so this method should not be executed on the first hand.

[philwebb]

Thanks. That's pretty interesting because I would have thought @ConditionalOnBean would kick-in. We'll have to investigate a little more.

[prasenjit-net]

@philwebb thanks, your workaround works for now

[wilkinsona]

We perhaps should try to find a way to make the names of our auto-configured beans more unique

See #4667

[wilkinsona]

I can't reproduce the exact behaviour that's described here, but I have identified a bug in BeanTypeRegistry.

I would expect the user-provide bean named auditEventRepository to be overridden by the auto-configured bean of the same name. This is what happens when I try to reproduce the described problem. BeanTypeRegistry doesn't notice that the bean has been overridden (lastDefinitionBeanCount == beanFactory.getBeanDefinitionCount()) so its view of the types of the beans in the bean factory is stale. As a result, conditions that match on the presence of an org.springframework.boot.actuate.audit.AuditEventRepository fail to match even though the bean is actually present.

BeanTypeRegistry needs to update beanTypes when an override occurs.

[wilkinsona]

@prasenjit-net I think that the problem you have reported has the same root cause as the problem that I have described above. My suspicion is that BeanTypeRegistry has an out of date view of the types of the beans in the bean factory so that a conditional on bean is matching when it should not. So that we can be sure that both problems have the same underlying cause, can you please provide a small sample (something that we can unzip or git clone and run) that reproduces the behaviour you have described?