Skip to content

indexing does not (yet) analyze beans in more detail when defined via @Bean method #1462

@martinlippert

Description

@martinlippert

At the moment, the indexer creates matching Bean elements for beans that are defined via @Bean annotated methods. However, more details that might belong to the bean definition are often not taken into account this way.

One example is the indexing for EventListener beans:

public class EventListenerPerInterfaceAndBeanMethod implements ApplicationListener<ApplicationEvent> {

	@Override
	public void onApplicationEvent(ApplicationEvent event) {
		...
	}

}

where the corresponding bean definition is included in a @Configuration class, e.g.:

@Bean
public EventListenerPerInterfaceAndBeanMethod listenerBean() {
	return new EventListenerPerInterfaceAndBeanMethod();
}
	

At runtime, this bean is notified of ApplicationEvents. However, the indexer only takes this into account and creates corresponding EventListenerIndexElement objects as children for the index element of the bean this event listener belongs to - in case the listener is defined as a @Component itself. In that case, @EventListener annotated methods as well as handleEvent methods via the ApplicationListener interface implementation are taken into account. In case the listener is defined using a @Bean annotated method, this doesn't happen.

The reason for this is that the event indexing happens for @EventListener annotations when there is a parent bean defined for the same source file (via the symbol provider for @EventListener) or via the symbol provider for @Component in case the ApplicationListener interface is implemented.

The solution would be to index the type that is used for the @Bean method when indexing the @Bean annotated method (so looking into the type of the bean itself), but that is not easy. The indexer can easily look into the referenced type, but can't easily create location objects for whatever it finds in there, since it looks at resolved type bindings, not source code anymore. We need to investigate this in more detail.

The events example is probably only the tip of the iceberg.

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions