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

@Configuration(prefix = "aabb") (or: how to create reusable configurations) [SPR-14103] #18675

Open
spring-projects-issues opened this issue Mar 31, 2016 · 3 comments
Labels
in: core type: enhancement

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Mar 31, 2016

Stepan Koltsov opened SPR-14103 and commented

Requesting a

@Configuration(prefix = "aabb-")

attribute. When prefix is specified, it is prepended to names of all beans defined in that @Configuration.

Why is it important: to create reusable configurations. For example, one might have database connection component which comprises of: DataSource, DataSourceMonitoring, ThreadPool etc.

It could be written like this:

abstract class DbContextTemplate {
    abstract String dbHost();
  
    @Bean DataSource dataSource() {
        return new DataSourceImpl(dbHost);
    }

    @Bean DataSourceMonitoring dataSourceMonitoring() {
        return new DataSourceMonitoring(dataSource());
    }

    ... ten more bean definitions
}

@Configuration(prefix = "primary-")
class PrimaryDbContext extends DbContextTemplate {
    String dbHost() { return "primary.host"; }
}

@Configuration(prefix = "another-")
class AnotherDbContext extends DbContextTemplate {
    String dbHost() { return "secondary"; }
}

With "prefix" attribute these configurations emit beans with names "primary-dataSource", "primary-dataSourceMonitoring", "another-dataSource", "another-dataSourceMonitoring".

However, currently Spring has no anything like "prefix" attribute, so this configuration is not possible, since generated bean names for "dataSource" would be the same for both subclass configurations.

Generally, it is not currently possible in Spring to create reusable configurations (configurations which could be used more than once in the application context). It would be good to have it in large applications.


Affects: 4.2.5

Reference URL: http://stackoverflow.com/questions/36298227/spring-how-to-reuse-the-same-configuration-multiple-times

Issue Links:

  • #18794 @Configuration interface with Java 8 default methods (as a standalone artifact)

4 votes, 5 watchers

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Apr 4, 2017

Juergen Hoeller commented

Stéphane Nicoll, Brian Clozel, Phil Webb, any opinions on this one? Do you see such prefixed naming per configuration class as useful within a Boot environment, and would you expose it as a prefix attribute at the @Configuration level or rather some other way?

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Apr 4, 2017

Phil Webb commented

I don't see it being particularly useful for Boot users. Personally I think it's a little confusing to add it as a feature to @Configuration, it's not immediately clear that prefix changes names of @Bean methods. It's a little more work, but I think the existing ImportBeanDefinitionRegistrar interface works quite well for this kind of thing:

@EnableDatabase("primary")
@EnableDatabase("another")
@Configuration
public class MyConfiguration {
}

The prefix is only really useful if you have configuration you want to reuse and it defines more than one bean.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Apr 5, 2017

Juergen Hoeller commented

Alright, since we're time-bound for 5.0 now, let's move this to the backlog for further votes and further feedback.

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

No branches or pull requests

1 participant