Due to the project upgrade, I encountered this problem and found many solutions. To no avail.
Some say that there is no reference to the jdbc package; some say that the DataSource needs to be excluded from the startup class, but it can't be solved.
Finally found this article, because the project structure was not made by myself, the references inside are super complicated, and the structure is also very complicated. In the end, the architects solved it by themselves, but I think it was caused by the reasons mentioned below.
The author’s article is reproduced as a record. Quack quack.
org.springframework.context.ApplicationContextException: Unable to start
web server; nested exception is java.lang.RuntimeException:
org.springframework.beans.factory.BeanCreationException: Error creating
bean with name 'servletEndpointRegistrar' defined in class path resource
[org/springframework/boot/actuate/autoconfigure/endpoint/web/ServletEndpointManagementContextConfiguration$WebMvcServletEndpointManagementContextConfiguration.class]: Bean instantiation via factory method failed;
nested exception is
org.springframework.beans.BeanInstantiationException: Failed to
instantiate
[org.springframework.boot.actuate.endpoint.web.ServletEndpointRegistrar]: Factory method 'servletEndpointRegistrar' threw exception; nested
exception is org.springframework.beans.factory.BeanCreationException:
Error creating bean with name 'healthEndpoint' defined in class path
resource
[org/springframework/boot/actuate/autoconfigure/health/HealthEndpointConfiguration.class]: Bean instantiation via factory method failed; nested
exception is org.springframework.beans.BeanInstantiationException:
Failed to instantiate
[org.springframework.boot.actuate.health.HealthEndpoint]: Factory method
'healthEndpoint' threw exception; nested exception is
org.springframework.beans.factory.BeanCreationException: Error creating
bean with name
'org.springframework.boot.actuate.autoconfigure.jdbc.DataSourceHealthIndicatorAutoConfiguration': Bean instantiation via constructor failed;
nested exception is
org.springframework.beans.BeanInstantiationException: Failed to
instantiate
[org.springframework.boot.actuate.autoconfigure.jdbc.DataSourceHealthIndicatorAutoConfigurationEnhancerBySpringCGLIB96597db7]: Constructor
threw exception; nested exception is
org.springframework.beans.factory.BeanCreationException: Error creating
bean with name 'dataSource': Post-processing of FactoryBean's singleton
object failed; nested exception is
org.springframework.beans.factory.BeanCreationException: Error creating
bean with name 'scopedTarget.dataSource' defined in class path resource
[org/springframework/boot/autoconfigure/jdbc/DataSourceConfiguration$Hikari.class]: Bean instantiation via factory method failed; nested
exception is org.springframework.beans.BeanInstantiationException:
Failed to instantiate [com.zaxxer.hikari.HikariDataSource]: Factory
method 'dataSource' threw exception; nested exception is
org.springframework.boot.autoconfigure.jdbc.DataSourceProperties$DataSourceBeanCreationException: Failed to determine a suitable driver classsolve:
The above error is actually caused by the JDBC database connection pool not reading the configuration information when loading multiple data sources.
In order to describe this problem clearly, I assume that there is a Maven project A. B, C, and D are sub-modules of A (Maven Module), and B is the basic module of A. Regardless of whether the C and D modules exist, as long as A starts, it must be dependent. B.
Under normal circumstances, B is packaged with the main class, and C and D are packaged without the main class as a component package when Maven is packaged. In this way, modules B, C and D can be decoupled.
But this time the error is that the JDBC connection pool code is in the B module, and when B+D, the database connection pool configuration is not included in the Config Server configuration of D (there is no data source configuration information in the Gitlab warehouse configuration). Therefore, there is no connection pool information in the checkout file. And B needs to load the JDBC connection pool at startup, so an error is reported because the configuration information cannot be read.
In the face of this situation, either change the project architecture, or add connection pool information to the configuration file of D (if this is the case, it is recommended to configure it in the bootstrap.yml of the local project, because GitLab is a public configuration. Don't move if you don't need it. I would rather differentiate the configuration files locally according to the environment. Of course, it is best to refactor the project structure a bit.
Transfer from: https://blog.csdn.net/kida_yuan/article/details/100691001