Jon Schneider opened SPR-16784 and commented

I have two cases I run across regularly enough:

  1. Configuration of some bean or @Configuration fails due to the lack of an injectable resource, generating an unhelpful stack trace like this:

!image-2018-04-30-13-39-55-761.png!

  1. Configuration of some bean or @Configuration succeeds, but I want to disable the feature in my application and don't know enough about the chain of events that leads to this configuration. For example, I wanted to disable Cassandra persistence in a Spinnaker project last week, and while it is was obvious enough to see Spinnaker Cassandra components logging after a successful app startup, it wasn't easy to track what caused these components to come into existence in the first place.

Build tools have a "reverse dependency insight" feature that is used to understand the chain of events that lead to binary dependencies existing in certain configurations, and I think a similar mechanism for Spring-managed beans would also be useful.

!image-2018-04-30-13-42-55-115.png!

Affects: 5.0.5

Attachments: - image-2018-04-30-13-39-55-761.png (287.90 kB) - image-2018-04-30-13-42-55-115.png (289.12 kB)

Comment From: spring-projects-issues

Jon Schneider commented

At first blush, the mechanism I would like is to supply an argument to a Spring Boot application that generates the dependency chain regardless of whether configuration succeeds or fails, e.g. --explain=ExecutionRepository

Comment From: snicoll

The NoSuchBeanDefinitionException should be accompanied with a dependency descriptor that provides more information about the component that requests injection.

1 & 2 are covered by Spring Boot's auto-configuration report. It can also be shown when the application failed to start.