can't start application with spring boot 3.3.2 (logback-access-spring-boot-starter 4.2.2)

[huntkalio]

qos-ch/logback-access#17

Error starting ApplicationContext. To display the condition evaluation report re-run your application with 'debug' enabled.
2024-08-26 15:19:43.565 ERROR - org.springframework.boot.diagnostics.LoggingFailureAnalysisReporter:40[main] - 

***************************
APPLICATION FAILED TO START
***************************

Description:

An attempt was made to call a method that does not exist. The attempt was made from the following location:

    org.springframework.boot.autoconfigure.web.embedded.TomcatWebServerFactoryCustomizer.customizeMaxQueueCapacity(TomcatWebServerFactoryCustomizer.java:170)

The following method did not exist:

    'void org.apache.coyote.AbstractProtocol.setMaxQueueSize(int)'

The calling method's class, org.springframework.boot.autoconfigure.web.embedded.TomcatWebServerFactoryCustomizer, was loaded from the following location:

    jar:file:/opt/xxxxxx/lib/spring-boot-autoconfigure-3.3.2.jar!/org/springframework/boot/autoconfigure/web/embedded/TomcatWebServerFactoryCustomizer.class

The called method's class, org.apache.coyote.AbstractProtocol, is available from the following locations:

    jar:file:/opt/xxxxxx/lib/tomcat-coyote-10.0.27.jar!/org/apache/coyote/AbstractProtocol.class
    jar:file:/opt/xxxxxx/lib/tomcat-embed-core-10.1.26.jar!/org/apache/coyote/AbstractProtocol.class

The called method's class hierarchy was loaded from the following locations:

    org.apache.coyote.AbstractProtocol: file:/opt/xxxxxx/lib/tomcat-coyote-10.0.27.jar

[janguntowski]

We experienced this, too. For now the fix is to completely exclude the transitive dependencies to catalina and coyote, which at least in our use case did not break anything else.

Noteworthy, we did not experience this when running applications with the mvn spring-boot plugin but only after building and running a docker image with JIB, most likely because the way JIB places the dependencies leads to a different behavior of the class loader (Did not dive into this because the exclusion fixed it for us)

[DanielSvanstrom]

We experienced this, too. For now the fix is to completely exclude the transitive dependencies to catalina and coyote, which at least in our use case did not break anything else.

Noteworthy, we did not experience this when running applications with the mvn spring-boot plugin but only after building and running a docker image with JIB, most likely because the way JIB places the dependencies leads to a different behavior of the class loader (Did not dive into this because the exclusion fixed it for us)

The order which libraries and classes are loaded can be very different. It can vary from time to time. We have it set up in approximately ten different applications. Two of them failed and the rest started up. So consider the order in which classes are loaded to be random and "removing the duplicate" as you did is the only safe way.

[sruffatti]

I ran into this. I had to exclude a few dependencies from logback-access-spring-boot-starter

<dependency>
            <groupId>dev.akkinoc.spring.boot</groupId>
            <artifactId>logback-access-spring-boot-starter</artifactId>
            <exclusions>
                <exclusion>
                    <groupId>org.apache.tomcat</groupId>
                    <artifactId>tomcat-catalina</artifactId>
                </exclusion>
                <exclusion>
                    <groupId>org.apache.tomcat</groupId>
                    <artifactId>tomcat-coyote</artifactId>
                </exclusion>
            </exclusions>
        </dependency>