Spring Boot provides a nice model of being opinionated out of the box and getting out of the way otherwise. However, when working on a large codebase or one that a developer is new two, there can be a lot of different places configuration lives. A user may think that Spring Boot is providing the configuration of a particular bean when in actuality, someone else is.

Currently in the debug report, when a bean is found that meets the condition, the name of the bean is emitted. However, some beans have generic names like dataSource or transactionManager and may be handled in many different ways (looking in Boot, you'd have both the DataSourceTransactionManager and the JpaTransactionManager for example). It would be useful to provide where the matching bean was configured (the Resource it's found in for XML config, the factory method info for java config).

Comment From: wilkinsona

Thanks for the suggestion. I agree that the extra information will be useful. It'll come at a performance cost as we'll have to make some extra calls to the bean factory to get the bean definition from which we can extract the extra information. Hopefully that cost won't be prohibitive.

Comment From: wilkinsona

There's a bit more to this than originally met the eye. Here's some work in progress:

   WebMvcAutoConfiguration.WebMvcAutoConfigurationAdapter#viewResolver matched:
      - @ConditionalOnBean (types: org.springframework.web.servlet.ViewResolver; SearchStrategy: all) found beans:
         - defaultViewResolver (declared in class path resource [org/springframework/boot/autoconfigure/web/servlet/WebMvcAutoConfiguration$WebMvcAutoConfigurationAdapter.class])
         - beanNameViewResolver (declared in class path resource [org/springframework/boot/autoconfigure/web/servlet/error/ErrorMvcAutoConfiguration$WhitelabelErrorViewConfiguration.class])
         - mvcViewResolver (declared in class path resource [org/springframework/boot/autoconfigure/web/servlet/WebMvcAutoConfiguration$EnableWebMvcConfiguration.class])
; @ConditionalOnMissingBean (names: viewResolver; types: org.springframework.web.servlet.view.ContentNegotiatingViewResolver; SearchStrategy: all) did not find any beans (OnBeanCondition)

   CodecsAutoConfiguration.JacksonCodecConfiguration#jacksonCodecCustomizer matched:
      - @ConditionalOnBean (types: com.fasterxml.jackson.databind.ObjectMapper; SearchStrategy: all) found bean:
         - jacksonObjectMapper (declared in class path resource [org/springframework/boot/autoconfigure/jackson/JacksonAutoConfiguration$JacksonObjectMapperConfiguration.class])
 (OnBeanCondition)

I like the extra information, and I think it'll prove very useful. I haven't run any performance numbers yet to know if the extra calls to the bean factory are prohibitively costly.

Things that I don't like:

  • (OnBeanCondition) being tacked on the end
  • @ConditionalOnBean and @ConditionalOnMissingBean being output together (this happens because they both use the same condition implementation).

Comment From: wilkinsona

We think that https://github.com/spring-projects/spring-boot/issues/13415 is a prerequisite for this. If it is fixed as expected, the messages will be produced lazily which will alleviate the performance concerns.

Comment From: philwebb

We're cleaning out the issue tracker and closing issues that we've not seen much demand to fix. Feel free to comment with additional justifications if you feel that this one should not have been closed.