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

Support @Scope @ConfigurationProperties beans #41668

Closed
sfilipiak-inpost opened this issue Aug 1, 2024 · 4 comments
Closed

Support @Scope @ConfigurationProperties beans #41668

sfilipiak-inpost opened this issue Aug 1, 2024 · 4 comments
Labels
status: superseded An issue that has been superseded by another

Comments

@sfilipiak-inpost
Copy link

When using @ConfigurationProperties via either @ConfigurationPropertiesScan or @EnableConfigurationProperties, bean scope specified via @Scope is not respected.
On the other hand, when defining @ConfigurationProperties with additional @Configuration/@Component/@Bean annotation, specified scope is respected

Provided below is a sample application using spring boot 3.3.2

package configbug;

import org.springframework.beans.factory.config.ConfigurableBeanFactory;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.boot.context.event.ApplicationReadyEvent;
import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.boot.context.properties.EnableConfigurationProperties;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.Scope;
import org.springframework.context.event.EventListener;
import org.springframework.stereotype.Component;

@SpringBootApplication
@EnableConfigurationProperties(ConfigBugApplication.MyProperties.class)
public class ConfigBugApplication {

    public static void main(String[] args) {
        SpringApplication.run(ConfigBugApplication.class, args);
    }

    @Scope(ConfigurableBeanFactory.SCOPE_PROTOTYPE)
    @ConfigurationProperties("my.properties")
    public static class MyProperties {
        private String value;
    }

    @Component
    @Scope(ConfigurableBeanFactory.SCOPE_PROTOTYPE)
    @ConfigurationProperties("my.other.properties")
    public static class MyOtherProperties {
        private String value;
    }

    @Configuration
    @Scope(ConfigurableBeanFactory.SCOPE_PROTOTYPE)
    @ConfigurationProperties("my.yet.another.properties")
    public static class MyYetAnotherProperties {
        private String value;
    }

    @ConfigurationProperties("my.yet.yet.another.properties")
    public static class MyYetYetAnotherProperties {
        private String value;
    }

    @Bean
    @Scope(ConfigurableBeanFactory.SCOPE_PROTOTYPE)
    MyYetYetAnotherProperties myYetYetAnotherProperties() {
        return new MyYetYetAnotherProperties();
    }

    @EventListener
    public void ready(ApplicationReadyEvent event) {
        var applicationContext = (AnnotationConfigApplicationContext) event.getApplicationContext();
        System.out.printf("MyProperties scope = '%s'%n", applicationContext.getBeanDefinition("my.properties-configbug.ConfigBugApplication$MyProperties").getScope());
        System.out.printf("MyOtherProperties scope = '%s'%n", applicationContext.getBeanDefinition("configBugApplication.MyOtherProperties").getScope());
        System.out.printf("MyYetAnotherProperties scope = '%s'%n", applicationContext.getBeanDefinition("configBugApplication.MyYetAnotherProperties").getScope());
        System.out.printf("MyYetYetAnotherProperties scope = '%s'%n", applicationContext.getBeanDefinition("myYetYetAnotherProperties").getScope());
    }

}

It prints following result

MyProperties scope = ''
MyOtherProperties scope = 'prototype'
MyYetAnotherProperties scope = 'prototype'
MyYetYetAnotherProperties scope = 'prototype'

It seems that the following if statement in ConfigurationPropertiesScanRegistrar is causing it to behave differently

private void register(ConfigurationPropertiesBeanRegistrar registrar, Class<?> type) {
        if (!isComponent(type)) {
	        registrar.register(type);
        }
}

private boolean isComponent(Class<?> type) {
        return MergedAnnotations.from(type, SearchStrategy.TYPE_HIERARCHY).isPresent(Component.class);
}

and the registrar itself registers properties with default scope.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Aug 1, 2024
@snicoll
Copy link
Member

snicoll commented Aug 1, 2024

This is working as designed. The Scope annotation defines how it should be used and it matches your sample above.

@snicoll snicoll closed this as not planned Won't fix, can't repro, duplicate, stale Aug 1, 2024
@snicoll snicoll added status: invalid An issue that we don't feel is valid and removed status: waiting-for-triage An issue we've not yet triaged labels Aug 1, 2024
@wilkinsona
Copy link
Member

The javadoc of @Scope says the following:

When used as a type-level annotation in conjunction with @Component indicates the name of a scope to use for instances of the annotated type.

It's not a huge leap from there to @EnableConfigurationProperties or @ConfigurationPropertiesScan defining a bean and wanting to be able to control its scope. I think it's worth at least considering an expansion of when @Scope is honoured to include "components" that are defined through @EnableConfigurationProperties or @ConfigurationPropertiesScan.

@wilkinsona wilkinsona added the for: team-meeting An issue we'd like to discuss as a team to make progress label Aug 1, 2024
@sfilipiak-inpost
Copy link
Author

@snicoll I see your point, that defining @ConfigurationProperties beans via @EnableConfigurationProperties or @ConfigurationPropertiesScan is not an orthodox way of defining spring framework beans. However I believe it would be great if spring boot could define those beans in a 'spring framework compatible' way.

@philwebb philwebb added type: enhancement A general enhancement and removed status: invalid An issue that we don't feel is valid for: team-meeting An issue we'd like to discuss as a team to make progress labels Aug 12, 2024
@philwebb philwebb added this to the 3.x milestone Aug 12, 2024
@philwebb philwebb changed the title @ConfigurationProperties bean definition does not respect @Scope Support @Scope @ConfigurationProperties beans Aug 12, 2024
@philwebb philwebb reopened this Aug 12, 2024
nosan added a commit to nosan/spring-boot that referenced this issue Aug 31, 2024
nosan added a commit to nosan/spring-boot that referenced this issue Sep 1, 2024
nosan added a commit to nosan/spring-boot that referenced this issue Sep 1, 2024
@philwebb
Copy link
Member

philwebb commented Sep 3, 2024

Closing in favor of PR #42073. Thanks @nosan!

@philwebb philwebb closed this as not planned Won't fix, can't repro, duplicate, stale Sep 3, 2024
@philwebb philwebb added status: superseded An issue that has been superseded by another and removed type: enhancement A general enhancement labels Sep 3, 2024
@philwebb philwebb removed this from the 3.x milestone Sep 3, 2024
nosan added a commit to nosan/spring-boot that referenced this issue Sep 5, 2024
nosan added a commit to nosan/spring-boot that referenced this issue Sep 5, 2024
nosan added a commit to nosan/spring-boot that referenced this issue Sep 5, 2024
nosan added a commit to nosan/spring-boot that referenced this issue Sep 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: superseded An issue that has been superseded by another
Projects
None yet
Development

No branches or pull requests

5 participants