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

context register @Configuration doesn't respect @Order [SPR-12657] #17257

Closed
spring-issuemaster opened this issue Jan 22, 2015 · 11 comments

Comments

@spring-issuemaster
Copy link
Collaborator

commented Jan 22, 2015

Yanming Zhou opened SPR-12657 and commented

according to http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/context/annotation/PropertySource.html

@Order(1)
@Configuration
 @PropertySource("classpath:/com/myco/a.properties")
 public class ConfigA { }

@Order(-1)
 @Configuration
 @PropertySource("classpath:/com/myco/b.properties")
 public class ConfigB { }
<context:component-scan base-package="com.myco"/>

changing @Order of @Configuration doesn't affect property source overriding.


Issue Links:

  • #17527 Regression: @Primary annotation not working when overriding bean definition with classpath scanning

Referenced from: commits f5b4e18

0 votes, 6 watchers

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Mar 13, 2015

Juergen Hoeller commented

As of 4.2, we sort all top-level configuration class candidates by @Order value (note: just the annotation, with the Ordered interface not supported for this purpose) before starting to process them. Any imported or otherwise lazily determined configuration classes will be processed in the regular order of registration, since they are not part of the initial ordering.

Juergen

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Mar 24, 2015

Andy Wilkinson commented

This change has broken a number of tests in Spring Boot due to its use of @Order to order auto-configuration classes in its DeferredImportSelector. It's a deferred import selector as we always want auto-configuration classes to be processed after any other configuration. This should, I believe, still work fine in normal running but causes problems in our tests.

A typical test doesn't use the import selector but simply relies on the configuration registration order being honoured. For example:

this.context.register(MultipartConfiguration.class,
		ServerPropertiesAutoConfiguration.class,
		DispatcherServletAutoConfiguration.class);

The ordering here is deliberate. MultipartConfiguration needs to be processed before the two auto-configuration classes. Unfortunately, DispatcherServletAutoConfiguration is annotated with @Order(Ordered.HIGHEST_PRECEDENCE) so, when we use Spring Framework 4.2, it's processed before MultipartConfiguration which causes the test to fail.

We could change Spring Boot to work around this behaviour change, but Stephane encouraged me to comment here in case there's anything that can be done in the framework .

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Mar 24, 2015

Juergen Hoeller commented

Why is DispatcherServletAutoConfiguration annotated with @Order then? In which context was it meant to be significant?

I'm afraid there's not much we can do about it since the whole point of this change is that @Order becomes significant among configuration classes. I suppose we could somehow specifically order Boot's auto-configuration classes after regular configuration classes... We'd need a framework-level marker for auto-config classes then though, since currently the framework is unaware of that distinction.

Juergen

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Mar 24, 2015

Andy Wilkinson commented

The @Order on DispatcherServletAutoConfiguration is processed by Boot's AutoConfigurationSorter. It determines the ordering of auto-configuration classes returned from EnableAutoConfigurationImportSelector.selectImports. That worked fine in 4.1, but now has the side-effect of changing the order when the classes are passed directly to register in our tests.

I've prototyped a change that introduces @AutoConfigureOrder (alongside the existing @AutoConfigureBefore and @AutoConfigureAfter) to be used in place of @Order on auto-configuration classes.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Jun 24, 2015

Matt Benson commented

What direction did spring-boot end up taking on this? I have opened spring-cloud/spring-cloud-commons#40, which relates.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Jun 24, 2015

Andy Wilkinson commented

We use @AutoConfigureOrder rather than @Order on our auto-configuration classes now. See this commit for the details.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Dec 10, 2015

Yanming Zhou commented

It seems @PropertySource and @PropertySources priority doesn't respect @Order, tested with 4.2.3, is it a regression or never fixed ?

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Dec 10, 2015

Juergen Hoeller commented

I'm not aware of a regression here... We process @PropertySource along with each individual configuration class, so the behavior should simply follow configuration class ordering, and then the property source composition rules within that - just like when you manually registered your configuration classes in that order.

Juergen

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Dec 11, 2015

Yanming Zhou commented

I want use @Order control @PropertySource overriding, It is useful to define default @PropertySource in base framework and let applications to override it if necessary. I tested with 4.2.3 and it doesn't works, this issue is not resolved and should be reopen.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Dec 11, 2015

Juergen Hoeller commented

Could you please sketch a test for a case that you'd expect to work but which doesn't?

Keep in mind that @Order controls the order of processing, just like when relying on the order of registration in a setup without component scan. In other words, if your property source overriding works with explicit AnnotationConfigApplicationContext.register calls, it should also work with classpath scanning (and its unpredictability) as long as the @Order values on your configuration values suggest the same order.

Juergen

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Dec 11, 2015

Yanming Zhou commented

Sorry for my fault, It works �fine, my test failed because the key exists in system property and placeholder always resolved with system property.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.