spring-boot icon indicating copy to clipboard operation
spring-boot copied to clipboard

Receiver class defaultJoranConfigurator does not define or inherit an implementation of resolved method abstract void configure(ch.qos.logback.classic.LoggerContext) after upgrade to Spring Boot 3

Open sushmita77 opened this issue 1 year ago • 4 comments

I have moved to spring boot 3 and I hence now we use logback classic 1.4.7. My earlier working code used Logger logger = LoggerFactory.getLogger(Main.class). But now I get error:

receiver class defaultJoranConfigurator does not define or inherit an implementation of resolved method abstract void configure (ch.qos.logback.classic.LoggerContext).

We used slf4j Logger earlier.

sushmita77 avatar Jan 31 '24 10:01 sushmita77

It sounds like there's a problem with your classpath and your upgrade has left you with an incompatible mixture of versions. If you would like us to spend some more time investigating, please spend some time providing a complete yet minimal sample that reproduces the problem. You can share it with us by pushing it to a separate repository on GitHub or by zipping it up and attaching it to this issue.

wilkinsona avatar Jan 31 '24 10:01 wilkinsona

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

spring-projects-issues avatar Feb 07 '24 10:02 spring-projects-issues

I don't know if it's related but I also had problems with logback and slf4j. spring-boot-dependencies-3.2.2.pom defines logback.version with 1.4.14 and slf4j.version with 2.0.11. But logback-parent-1.4.14.pom defines slf4j.version with 2.0.7. This results to some incompabilities, e.g.

Exception in thread "main" java.lang.NoSuchMethodError: 'void org.slf4j.helpers.Util.report(java.lang.String, java.lang.Throwable)'
	at ch.qos.logback.classic.spi.LogbackServiceProvider.initializeLoggerContext(LogbackServiceProvider.java:63)
	at ch.qos.logback.classic.spi.LogbackServiceProvider.initialize(LogbackServiceProvider.java:41)
	at org.slf4j.LoggerFactory.bind(LoggerFactory.java:196)
	at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:183)
	at org.slf4j.LoggerFactory.getProvider(LoggerFactory.java:486)
	at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:472)
	at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:421)
	at org.apache.commons.logging.impl.SLF4JLogFactory.getInstance(SLF4JLogFactory.java:155)
	at org.apache.commons.logging.impl.SLF4JLogFactory.getInstance(SLF4JLogFactory.java:132)
	at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:273)
	at org.springframework.context.support.AbstractApplicationContext.<init>(AbstractApplicationContext.java:180)
	at org.springframework.context.support.GenericApplicationContext.<init>(GenericApplicationContext.java:122)

In my case the root cause was that I was using an if-condition in logback and didn't have janino in the classpath, but the logback-slf4j-version-mixup should probably be fixed anyway.

schabe77 avatar Feb 09 '24 23:02 schabe77

@schabe77 that problem's due to a mistake in SLF4J. It has now been corrected and released in 2.0.12 to which we'll upgrade in due course.

wilkinsona avatar Feb 12 '24 10:02 wilkinsona

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.

spring-projects-issues avatar Feb 24 '24 11:02 spring-projects-issues