AbstractApplicationContext#refresh omits exception trace and cause from the log

[Spikhalskiy]

This is an example of a log XmlWebApplicationContext produces when there is no certain classes in the classpath:

[03 Dec 2024 00:04:49,357][WARN ][XmlWebApplicationContext,main] - Exception encountered during context initialization - cancelling refresh attempt: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter': Cannot create inner bean '(inner bean)#736f2fb8' of type [org.springframework.web.bind.support.ConfigurableWebBindingInitializer] while setting bean property 'webBindingInitializer'
[03 Dec 2024 00:04:49,357][WARN ][ClassPathXmlApplicationContext,main] - Exception encountered during context initialization - cancelling refresh attempt: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'webContext' defined in class path resource [context/bootstrap.xml]: Error creating bean with name 'org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter': Cannot create inner bean '(inner bean)#736f2fb8' of type [org.springframework.web.bind.support.ConfigurableWebBindingInitializer] while setting bean property 'webBindingInitializer'

As you can see, this log completely omits any useful details and is not useful for tracking a root case.

The culprit is AbstractApplicationContext#refresh logging the exception in the following way:

catch (RuntimeException | Error ex ) {
				if (logger.isWarnEnabled()) {
					logger.warn("Exception encountered during context initialization - " +
							"cancelling refresh attempt: " + ex);
				}
                                //...
			}

The problem is present on all 6.x Spring versions.

The only way to trace a route cause was to put a breakpoint on the logging line in Spring code.

[jhoeller]

Note that this is just an extra log entry to appear in the common log category - which we intentionally keep brief since it usually sits next to to the actual exception being logged eventually. The actual exception bubbles up to the initializing thread, probably only visible in the Servlet container's log in your case?

[Spikhalskiy]

Thank you for the clarification. We, indeed, were having problems with log configuration, and that was the reason why the Spring message was the only thing we were observing.