The following is now possible:
@Configuration
public class AppConfig {
@Inject DataSource dataSource;
@Bean
public MyBean myBean() {
return new MyBean(dataSource);
}
@Configuration
static class DatabaseConfig {
@Bean
DataSource dataSource() {
return new EmbeddedDatabaseBuilder().build();
}
}
}
public static void main(String... args) {
AnnotationConfigApplicationContext ctx =
new AnnotationConfigApplicationContext(AppConfig.class);
ctx.getBean(MyBean.class); // works
ctx.getBean(DataSource.class); // works
}
Notice that the @Import annotation was not used and that only AppConfig
was registered against the context. By virtue of the fact that
DatabaseConfig is a member class of AppConfig, it is automatically
registered when AppConfig is registered. This avoids an awkward and
redundant @Import annotation when the relationship is already implicitly
clear.
See @Configuration Javadoc for details.
Issue: SPR-8186
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4343 50f2f4bb-b051-0410-bef5-90022cba6387
- removed generics from Cache/CacheManager (they add no value since it's an SPI not API)
+ update docs and tests
+ renamed ConcurrentCacheFactoryBean to ConcurrentMapCacheFactoryBean
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4326 50f2f4bb-b051-0410-bef5-90022cba6387
- eliminate unneeded methods
+ introduced value wrapper (name still to be decided) to avoid cache race conditions
+ improved name consistency
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4315 50f2f4bb-b051-0410-bef5-90022cba6387
A subtle issue existed with the way we relied on isCurrentlyInCreation
to determine whether a @Bean method is being called by the container
or by user code. This worked in most cases, but in the particular
scenario laid out by SPR-8080, this approach was no longer sufficient.
This change introduces a ThreadLocal that contains the factory method
currently being invoked by the container, such that enhanced @Bean
methods can check against it to see if they are being called by the
container or not. If so, that is the cue that the user-defined @Bean
method implementation should be invoked in order to actually create
the bean for the first time. If not, then the cached instance of
the already-created bean should be looked up and returned.
See ConfigurationClassPostConstructAndAutowiringTests for
reproduction cases and more detail.
Issue: SPR-8080
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4296 50f2f4bb-b051-0410-bef5-90022cba6387
Allows a convenient mechanism for contributing a PropertySource to the
enclosing Spring Environment. See @PropertySource Javadoc for
complete details and PropertySourceAnnotationTests for examples.
Issue: SPR-8314
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4289 50f2f4bb-b051-0410-bef5-90022cba6387
Declaring @Bean methods as 'static' is now permitted, whereas previously
it raised an exception at @Configuration class validation time.
A static @Bean method can be called by the container without requiring
the instantiation of its declaring @Configuration class. This is
particularly useful when dealing with BeanFactoryPostProcessor beans,
as they can interfere with the standard post-processing lifecycle
necessary to handle @Autowired, @Inject, @Value, @PostConstruct and
other annotations.
static @Bean methods cannot recieve CGLIB enhancement for scoping and
AOP concerns. This is acceptable in BFPP cases as they rarely if ever
need it, and should not in typical cases ever be called by another
@Bean method. Once invoked by the container, the resulting bean will
be cached as usual, but multiple invocations of the static @Bean method
will result in creation of multiple instances of the bean.
static @Bean methods may not, for obvious reasons, refer to normal
instance @Bean methods, but again this is not likely a concern for BFPP
types. In the rare case that they do need a bean reference, parameter
injection into the static @Bean method is technically an option, but
should be avoided as it will potentially cause premature instantiation
of more beans that the user may have intended.
Note particularly that a WARN-level log message is now issued for any
non-static @Bean method with a return type assignable to BFPP. This
serves as a strong recommendation to users that they always mark BFPP
@Bean methods as static.
See @Bean Javadoc for complete details.
Issue: SPR-8257, SPR-8269
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4281 50f2f4bb-b051-0410-bef5-90022cba6387
Prior to this change, @ComponentScan annotations were only processed at
the first level of depth. Now, the set of bean definitions resulting
from each declaration of @ComponentScan is checked for configuration
classes that declare @ComponentScan, and recursion is performed as
necessary.
Cycles between @ComponentScan declarations are detected as well. See
CircularComponentScanException.
Issue: SPR-8307
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4275 50f2f4bb-b051-0410-bef5-90022cba6387
Introduce @EnableAsync#order
AsyncAnnotationBeanPostProcessor's 'order' property is now mutable;
@EnableAsync's 'order()' attribute allows for setting it, but must
have a default value, thus uses the new Ordered#NOT_ORDERED
constant - a reserved negative number very unlikely to be otherwise
used that may be interpreted as 'not ordered', useful in annotation
defaulting scenarios where null is not an option.
Introduce first working cut of AsyncConfiguration
Remove AsyncCapability
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4265 50f2f4bb-b051-0410-bef5-90022cba6387
This change is in support of certain polymorphism cases in
@Configuration class inheritance hierarchies. Consider the following
scenario:
@Configuration
public abstract class AbstractConfig {
public abstract Object bean();
}
@Configuration
public class ConcreteConfig {
@Override@Bean
public BeanPostProcessor bean() { ... }
}
ConcreteConfig overrides AbstractConfig's #bean() method with a
covariant return type, in this case returning an object of type
BeanPostProcessor. It is critically important that the container
is able to detect the return type of ConcreteConfig#bean() in order
to instantiate the BPP at the right point in the lifecycle.
Prior to this change, the container could not do this.
AbstractAutowireCapableBeanFactory#getTypeForFactoryMethod called
ReflectionUtils#getAllDeclaredMethods, which returned Method objects
for both the Object and BeanPostProcessor signatures of the #bean()
method. This confused the implementation sufficiently as not to
choose a type for the factory method at all. This means that the
BPP never gets detected as a BPP.
The new method being introduced here, #getUniqueDeclaredMethods, takes
covariant return types into account, and filters out duplicates,
favoring the most specific / narrow return type.
Additionally, it filters out any CGLIB 'rewritten' methods, which
is important in the case of @Configuration classes, which are
enhanced by CGLIB. See the implementation for further details.
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4262 50f2f4bb-b051-0410-bef5-90022cba6387
Consolidating internal bean name and aspect class name constats within
AnnotationConfigUtils to allow access from both the context.config
and context.annotation packages without creating a relationship between
the two of them (they are unrelated leaf nodes in the packaging
currently).
The .transaction module does not have a similar utils class and already
has a relationship from transaction.config -> transaction.annotation,
so placing the constants in .annotation.TransactionManagementCapability
to be referenced by .config.AnnotationDrivenBeanDefinitionParser
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4261 50f2f4bb-b051-0410-bef5-90022cba6387
@Configuration classes may implement ImportAware in order to be injected
with the AnnotationMetadata of their @Import'ing class.
Includes the introduction of a new PriorityOrdered
ImportAwareBeanPostProcessor that handles injection of the
importing class metadata.
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4259 50f2f4bb-b051-0410-bef5-90022cba6387
Includes the introduction of AnnotationUtils#findAllAnnotationAttributes
to support iterating through all annotations declared on a given type
and interrogating each for the presence of a meta-annotation. See tests
for details.
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4258 50f2f4bb-b051-0410-bef5-90022cba6387
Previously errors were being raised when trying to inject @Value
annotated paramaters such as:
@Feature
public FeatureSpec feature(@Value("#{environment['foo']}") String foo) {
return new FeatureSpec(foo);
}
This is not so much because dependency resolution of @Value-annotated
types was failing, but rather because the 'early bean reference'
proxying mechanism was throwing an exception if any final type was
detected as a parameter. This is of course because final types are
non-subclassable by CGLIB. On review, however, it's obvious that
certain final types must be allowed for injection. @Value injection
is an obvious one, but the rarer case of a Spring bean of type String
or int is another.
The explicit guard against final types as parameters to @Feature methods
has been removed. Final types are still checked for, however, and if
found, no proxing is attempted. The dependency is immediately resolved
against the current BeanFactory and injected into the @Feature method.
This means that @Value injection, @Qualifier injection, etc all work
as expected, but does mean that premature bean instantiation may occur
if a user unwittingly injects non-String, non-primitive final bean types
as @Feature method parameters.
Issue: SPR-7974
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4094 50f2f4bb-b051-0410-bef5-90022cba6387
CGLIB-enhanced @Configuration subclasses now implement DisposableBean
such that Enhancer.registerStaticCallbacks(subclass, null) is invoked
on container shutdown. This ensures that garbage collection can work
properly and avoids memory consumption issues for applications that
create and destroy many application contexts within the same JVM.
Issue: SPR-7901
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4090 50f2f4bb-b051-0410-bef5-90022cba6387
Prove that injection of special container types such as ResourceLoader,
BeanFactory, etc already works with the current implementation of
@Feature methods.
Issue: SPR-7975
git-svn-id: https://src.springframework.org/svn/spring-framework/trunk@4082 50f2f4bb-b051-0410-bef5-90022cba6387
Chris Beams
Mark Fisher
Sam Brannen
Oliver Gierke
Keith Donald
Costin Leau
Micha Kiener