How to fix "Consider defining a bean of type 'org.jooq.DSLContext' in your configuration." after update to jOOQ 3.15.0 - spring

In my Vaadin and Spring Boot application, I have updated from jOOQ 3.14.12 to 3.15.0. After this update my application is not starting up again. This is the error I get:
***************************
APPLICATION FAILED TO START
***************************
Description:
Parameter 0 of constructor in org.komunumo.data.service.MemberService required a bean of type 'org.jooq.DSLContext' that could not be found.
Action:
Consider defining a bean of type 'org.jooq.DSLContext' in your configuration.
I don't understand why I have to define this bean, because with jOOQ 3.14.12 I did not have to. As far as I know, this is done by JooqAutoConfiguration automatically.

Spring Boot 2.6 answer
With Spring Boot 2.6, this issue no longer reproduces, see https://github.com/spring-projects/spring-boot/issues/26439
Spring Boot 2.5 answer
Starting from jOOQ 3.15.0, jOOQ ships with a built-in R2DBC dependency. Spring Boot 2.5 is not yet aware of this, and as such, you'll have to explicitly exclude R2dbcAutoConfiguration (not R2dbcDataAutoConfiguration!) from your spring boot application (unless you're using R2DBC with jOOQ, of course):
#SpringBootApplication(exclude = { R2dbcAutoConfiguration.class })
Note, you may see the following error message:
No qualifying bean of type 'org.jooq.DSLContext' available: expected at least 1 bean which qualifies as autowire candidate.
Which I'm adding here, because otherwise, people might not find this answer from Google.

Related

Resilience4J Retry not auto-configured in Spring boot 3

I'm in the process of migrating to Spring Boot 3. In Spring Boot 2 Resilience4J Retry was auto-configured and worked out of the box using the following setup:
application.yaml:
resilience4j.retry:
instances:
some-instance
# retry config here
Test class:
#SpringBootTest
public class TestClass {
#Autowired
private RetryRegistry retryRegistry;
#Test
void someTest() {
// perform test and evaluate retries using retryRegistry
}
}
However while updating to Spring Boot 3 using the following versions:
org.springframework.boot:spring-boot-starter:jar:3.0.0:compile
io.github.resilience4j:resilience4j-spring-boot2:jar:1.7.0:compile (derived from a Spring BoM)
The test in which the RetryRegistry was autowired failed with the following message:
Unsatisfied dependency expressed through field 'retryRegistry':
No qualifying bean of type 'io.github.resilience4j.retry.RetryRegistry' available:
expected at least 1 bean which qualifies as autowire candidate.
Dependency annotations: {#org.springframework.beans.factory.annotation.Autowired(required=true)}
I managed to fix the test by explicitly importing the Resilience4j Retry configuration in the test using:
#Import(io.github.resilience4j.retry.autoconfigure.RetryAutoConfiguration.class)
However, I'm wondering why the component scanning mechanism in Spring Boot 3 did not pick up the retry config in the first place. Would anyone know why Spring Boot 3 did not pick up the class during component scanning?
In the resilience4j project they changed the dependency for spring boot 3.
So you should go for io.github.resilience4j:resilience4j-spring-boot3:${resilience4jVersion}
like
org.springframework.boot:spring-boot-starter:jar:3.0.0:compile
io.github.resilience4j:resilience4j-spring-boot3:jar:2.0.0:compile
from the documentation
It seems that it is related to a new META-INF file being used instead of the old spring.factories file. From the documentation :
Spring Boot 2.7 introduced a new META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports file for registering auto-configurations, while maintaining backwards compatibility with registration in spring.factories. With this release, support for registering auto-configurations in spring.factories has been removed in favor of the imports file.
The Resilience4J dependency used in the spring-cloud-dependencies-parent BoM still uses a spring.factories file instead of the new file named org.springframework.boot.autoconfigure.AutoConfiguration.imports. The new file has recently been introduced in Resilience4J (source).
Overriding the version from the Spring BoM with version 2.0.2 for all the resilience dependencies fixed it for me. I will check in a few days whether the new Resilience4J version has been updated in the Spring BoM (or resilience4j-spring-boot3 has been introduced).
[edit]
As others have noticed,resilience4j-spring-boot3 is already available. I'll start using it.

springboot app looking for GenericResponseService bean

I am new to springboot.
Doing a migration of my service (kotlin)following a guide written at work.
Got this weird exception and cannot find any documentation.
Parameter 3 of method multipleOpenApiResource in org.springdoc.webflux.core.MultipleOpenApiSupportConfiguration required a bean of type 'org.springdoc.core.GenericResponseService' that could not be found.
Action:
Consider defining a bean of type 'org.springdoc.core.GenericResponseService' in your configuration.
Should I define this bean at my #Configuration?
Is this a symptom of dependency missing or bad dependency wiring?
One of my beans was called ResponseBuilder and it conflicted with spring boot.
Sorry for the trouble

why Spring boot 2.4.3 has migration issues related entityManagerFactory bean

I had a working application using spring boot 1.5.9
After i upgrade spring boot to latest 2.4.3, facing issues with
an interface with #Reposiroty - required a bean of type testRepository
then added #EnableJPAConfiguration to bootRunner got below error
required a bean named 'entityManagerFactory' that could not be found
If i a write LocalContainerEntityManagerFactoryBean bean with dataSource configuration, i could see the application starts.
I dont really see these details from this Migration Guide
https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-2.0-Migration-Guide
Kindly Please help me understanding this puzzle. Thank you.

Spring boot (1.3.6) + Hibernate(5.2.1) No qualifying bean of type [org.hibernate.SessionFactory] found for dependency:

While moving into micro-services from monolithic application, upon creating the micro-services using Spring boot (1.3.6) + Hibernate(5.2.1) we got an exception
org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type [org.hibernate.SessionFactory] found for dependency: expected at least 1 bean which qualifies as autowire candidate for this dependency. Dependency annotations: {}.
But the same source code is running on hibernate(4.3.11). Please find the source code on
https://github.com/pandiaraj2/Spring-boot-1.3.6-Hibernate-5.2
What do I need to do to resolve this error?
Spring Boot 1.3.6 uses Spring 4.2.x, which doesn't support Hibernate 5.2. You also have to upgrade Spring to 4.3, e.g. by adding the following property in your pom.xml:
<properties>
<spring.version>4.3.1.RELEASE</spring.version>
</properties>
But it still might be, that some of the autoconfigurations are not working, because full Hibernate support in Spring Boot will only be introduced in Spring Boot 1.4, which is still in release candidate.
i guess you need to add #EnableJpaRepositories annotation on your main class DtcmwsApplication and also need to remove exclusion for hibernate-entitymanager

Use CDI ConversationScoped beans in Spring Controllers

I'm trying to make webapp which should use thymeleaf with spring controllers. But I'd like to have some CDI ConversationScoped beans injected into my Spring controller. For now I managed to configure CDI with my Spring application I when I tried to incject CDI bean into my controller it seems to work fine, but when I tried to inject Conversation bean it fails with error:
org.springframework.beans.factory.NoSuchBeanDefinitionException: No matching bean of type [javax.enterprise.context.Conversation] found for dependency: expected at least 1 bean which qualifies as autowire candidate for this dependency. Dependency annotations: {#javax.inject.Inject()}
In CDI 1.0 the conversation scope is tied to JSF. If you're not using JSF you won't be able to access the conversation scope. You could create another scope which mimics the conversation scope though.

Resources