Spring-boot: Defining @ConfigurationProperties bean with same prefix generates invalid metadata

Created on 13 May 2016  路  7Comments  路  Source: spring-projects/spring-boot

@ConfigurationProperties("prefix")
public class Props { ... }
@Configuration
public class Config {

   @Bean
   @ConfigurationProperties("prefix")
   public Props myProps() {...}
}

will generate the same keys twice

expected: AP should stop processing

bug

Most helpful comment

Again, nothing I can't work around, but:

Why are you running the annotation processor on test classes?

Because this is what happens when you setup the processor the idiomatic way:

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-configuration-processor</artifactId>
            <optional>true</optional>
        </dependency>

Why are you defining @ConfigurationProperties beans in test classes?

Because in my particular case, dealing with Integration Tests, I need some @ConfigurationProperties to be setup to configure some parts of the IT (maven repository access in this example). It also happens that I have two IT classes to run, and each one needs it. So, sure, I can factor this out.

All 7 comments

Stop processing is a bit harsh at this point (especially if we want to fix that in a maintenance release). I'd go with ignoring the duplicate and log a warning. What do you think @wilkinsona @philwebb ?

Actually I forgot about the Messenger feature. We detect now such a case and prevent to compilation to complete. I am bit nervous about adding this to the maintenance release so I've fixed this on master only.

There are cases where it makes sense to have several declarations in a single set of source files (eg several integration tests). What about those?

@ericbottard Can you expand on that please? It sounds like you are declaring configuration properties beans in test code and running the annotation processor against that code. Why do you want to do that?

I've got the annotation processor defined "the usual way". So it applies to test sources as well.

As for the particular use case, I ended up needing to wanting to define a configuration bean in two ITs, like so:


@Bean
@ConfigurationProperties("myprefix")
public SomeBean foo() {
    ...
}

Thanks, Eric. Unfortunately, that explains the how but not the why. We need to know why you're doing this so that we can see if it's worth us worrying about it. Two specific questions:

  1. Why are you running the annotation processor on test classes?
  2. Why are you defining @ConfigurationProperties beans in test classes?

Again, nothing I can't work around, but:

Why are you running the annotation processor on test classes?

Because this is what happens when you setup the processor the idiomatic way:

        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-configuration-processor</artifactId>
            <optional>true</optional>
        </dependency>

Why are you defining @ConfigurationProperties beans in test classes?

Because in my particular case, dealing with Integration Tests, I need some @ConfigurationProperties to be setup to configure some parts of the IT (maven repository access in this example). It also happens that I have two IT classes to run, and each one needs it. So, sure, I can factor this out.

Was this page helpful?
0 / 5 - 0 ratings