That is true, there's a lot of "magic" that comes with boot. It can be helpful to take a look at what all of that auto-configuration code is actually doing, but reading that stuff is pretty difficult as well.
> It can be helpful to take a look at what all of that auto-configuration code is actually doing
You can't tell by reading it either, because it's all dynamic: all of the autoconfigurations create beans conditionally only if other beans of that type aren't defined, if certain classes are present on the classpath, if particular values are defined in the configuration that's written in magical self-transforming YAML, or all three. The only way I've found is to breakpoint at the point where something is wired in to see what the concrete class is, then breakpoint again in the constructor of that class to find where it's being constructed from, so you have to restart your application and run the (slow) spring boot startup twice for each thing you care about. And even that doesn't always work because spring encourages doing AOP with bytecode-manipulation-based proxies.
