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

PropertySources added via @PropertySource aren't available in the environment during component scanning [SPR-12111] #16727

Closed
spring-projects-issues opened this issue Aug 21, 2014 · 4 comments
Assignees
Labels
type: enhancement
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Aug 21, 2014

Andy Wilkinson opened SPR-12111 and commented

The property sources created via @PropertySource aren't added to the environment in time for them to be considered when component scanning triggers the evaluation of a profile condition. This means that beans discovered via component scanning and annotated with @Profile aren't instantiated.

The following should illustrate the problem:

package test;

import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.Profile;
import org.springframework.context.annotation.PropertySource;
import org.springframework.stereotype.Component;

@Configuration
@PropertySource("test.properties")
@ComponentScan
public class Application {
	
	public static void main(String[] args) {
		AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(Application.class);
		System.out.println(context.getBean(MyBean.class));
        System.out.println(context.getBean(MyComponentScannedBean.class));
	}
	
	@Bean
	@Profile("test")
	public MyBean myBean() {
		return new MyBean();
	}
	
	public class MyBean {
		
	}
	
	@Component
	@Profile("test")
	public static class MyComponentScannedBean {
		
	}
}
spring.profiles.active=test

When run, MyBean is found but MyComponentScannedBean is not.


Affects: 4.0.6

Reference URL: spring-projects/spring-boot#1417

Issue Links:

  • #16726 Placeholder resolution within @PropertySource resource locations can not resolve properties from prior sources
  • #16731 PropertySource named cannot be added relative to itself (@PropertySource processing fails)

Referenced from: commits 7c60888

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Aug 21, 2014

Juergen Hoeller commented

It's not really well-defined whether a property source declared on a configuration class is applicable to the component scan run triggered by the same configuration class to begin with. It is kind of intended to only rely on the state at the beginning of the configuration class parsing phase at this point.

That said, admittedly, this may be rather unintuitive. I'll see what I can do for 4.1 there.

Juergen

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Aug 21, 2014

Andy Wilkinson commented

The differing behaviour between a bean declared via @Bean and a bean found via component scanning certainly wasn't intuitive to me. I'd expected both to work or neither to work.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Aug 21, 2014

Juergen Hoeller commented

Good point about the difference between regular @Bean processing and scanned beans. Fixed for 4.1 GA through a reordering of the processing algorithm, along with #16726.

I'm afraid this doesn't suggest itself as a candidate for backporting. Can we simply consider this a limitation with 4.0.x? There are workarounds, after all...

Juergen

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Aug 22, 2014

Andy Wilkinson commented

I think it's reasonable to only make the change in 4.1. It's a change in behaviour so it might catch someone out if it were made in a maintenance release.

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

No branches or pull requests

2 participants