Show stacktraces for context startup failures

[shollander]

Using Spring Boot 2.0.3.RELEASE and executing application using Spring Boot fat jar with java -jar.

If the application context fails to startup for some reason (for example, a @Bean method throws an exception), I get no stacktrace information. The only log of the error that I get is a warning that just includes the toString() of the exception (logged in AbstractApplicationContext.refresh()). I just have a simple main setup like this:

@SpringBootApplication
public class Application {
	public static void main(String[] args) {
		SpringApplication.run(Application.class, args);
	}
}

The only way the I can get more useful information is to wrap the call to SpringApplication.run() in a try/catch and log my own exception.

[wilkinsona]

Stack traces or failure analysis should already be shown. Can you please provide a sample where this does not happen?

[shollander]

Ok, I see what you are referring to. SpringApplication.reportFailure() is supposed to log the failure including stacktrace.

After a lot of debugging I finally figured out what the issue is. I am including a dependency that includes commons-logging:commons-logging:1.2 as a dependency. It looks like Spring has its own version of the commons-logging API in spring-jcl. Even though spring-jcl was being transitively included on my classpath, commons-logging was listed first so that was the one that was being used upon the call to LogFactory.getLog(). Apparently the original commons-logging implementation does not work well with Spring (or Spring Boot perhaps), I guess that's the reason why spring-jcl exists. For some reason, commons-logging was not detecting my logging implementation (default spring-starter-logging) and instead giving me JUL. Therefore I was not seeing the log. For other reasons that I don't fully understand, I did get some log messages from Spring. I was just this specific log statement that got lost.

Long story short, I put a dependencySubstitution in my build.gradle to use spring-jcl instead of commons-logging and that fixed my issue.

I'm thinking that there should be a better way of doing this so that no one else encounters this issue which was very difficult to debug.

[wilkinsona]

Thanks for the additonal information. This is a duplicate of #12457. The situation will be improved in a future Spring Framework release (see SPR-16585).