Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spring @WebMvcTest stopped working with ShedLock 6.0.1 #2272

Closed
waschmittel opened this issue Nov 25, 2024 · 3 comments
Closed

Spring @WebMvcTest stopped working with ShedLock 6.0.1 #2272

waschmittel opened this issue Nov 25, 2024 · 3 comments

Comments

@waschmittel
Copy link

waschmittel commented Nov 25, 2024

Since version 6.0.1, Spring @WebMvcTest stopped working with the following error message

No qualifying bean of type 'net.javacrumbs.shedlock.core.LockProvider' available: No LockProvider bean found.

According to documentation, @WebMvcTest only enables auto-configuration that is relevant to MVC tests, which is why our LockProvider Bean cannot be found.

However, it should not be needed in the first place (as it was in 5.x.x), and providing it via @Import(SchedlockConfig.class) is no viable solution because that requires a DataSource bean which is exactly what a @WebMvcTest should not need.

our configuration:

@Configuration
public class SchedlockConfig {

    @Bean
    public LockProvider lockProvider(DataSource dataSource) {
        return new JdbcTemplateLockProvider(
                JdbcTemplateLockProvider.Configuration.builder()
                        .withJdbcTemplate(new JdbcTemplate(dataSource))
                        .usingDbTime()
                        .build()
        );
    }
}

Our application is annotated with @EnableSchedulerLock(interceptMode = PROXY_METHOD)

@lukas-krecan
Copy link
Owner

Thanks, I will look into that. There were some changes in this area (that's actually the reason for the major release)

@lukas-krecan
Copy link
Owner

As a workaround you can move the @EnableSchedulerLock to the SchedlockConfig. Applying it to Application is not necessary.

The behavior indeed changed in 6.0.1. I like the new behavior better - to fail on startup if LockProvider is missing, but I prefer maintianing backward compatiblility more, so I will most likely revert it to the original behavior #2274.

Thanks again for reporting

lukas-krecan added a commit that referenced this issue Nov 25, 2024
 #2272 Do not fail in startup time if LockProvider is not found
@lukas-krecan
Copy link
Owner

Released in 6.0.2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants