- 23 5月, 2011 8 次提交
-
-
由 Chris Beams 提交于
AnnotationConfigApplicationContext and AnnotationConfigWebApplicationContext both expose #register and #scan methods as of the completion of SPR-8320. This change introduces a new interface that declares each of these methods and refactors ACAC and ACWAC to implement it. Beyond information value, this is useful for implementors of the ApplicationContextInitializer interface, in that users may create an ACI that works consistently across ACAC and ACWAC for standalone (e.g. testing, batch) or web (e.g. production) use. Issue: SPR-8365,SPR-8320
-
由 Chris Beams 提交于
Primarily for use in conjunction with ApplicationContextInitializer, these new #scan and #register methods mirror those in AnnotationConfigApplicationContext. #setConfigLocation and #setConfigLocations methods remain for compatibility with ContextLoader-style initialization, but have been locally overridden and documented clearly. AnnotationConfigWebApplicationContext#loadBeanDefinitions Javadoc has also been updated to explain the processing logic for each of these potential inputs. Issue: SPR-8320
-
由 Chris Beams 提交于
FrameworkServlet now has support equivalent to ContextLoader and its "contextInitializerClasses" context-param introduced in 3.1 M1. This allows users to specify ApplicationContextInitializers at the root (ContextLoader) level and/or at the DispatcherServlet level. Issue: SPR-8366
-
由 Chris Beams 提交于
-
由 Keith Donald 提交于
-
由 Keith Donald 提交于
revised findCommonElement handling within TypeDescriptor.forObject(Object); we now fully introspect the collection elements to resolve the common type. We also support nested introspection e.g. collections of collections. Object.class is used to indicate no common type, and TypeDescriptor.NULL is used to indicate a null element value
-
由 Keith Donald 提交于
-
由 Keith Donald 提交于
-
- 21 5月, 2011 5 次提交
-
-
由 Chris Beams 提交于
Issue: SPR-8358,SPR-8186
-
由 Chris Beams 提交于
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
-
由 Chris Beams 提交于
ClassMetadata implementations can now introspect their member (nested) classes. This will allow for automatic detection of nested @Configuration types in SPR-8186. Issue: SPR-8358,SPR-8186
-
由 Chris Beams 提交于
-
由 Rossen Stoyanchev 提交于
SPR-7353 Respect 'produces' condition in ContentNegotiatingViewResolver, improve selection of more specific media type in a pair
-
- 20 5月, 2011 9 次提交
-
-
由 Chris Beams 提交于
Issue: SPR-8348
-
由 Chris Beams 提交于
Issue: SPR-8348
-
由 Chris Beams 提交于
Issue: SPR-8348
-
由 Chris Beams 提交于
-
由 Chris Beams 提交于
This new hook in the AbstractEnvironment lifecycle allows for more explicit and predictable customization of property sources by subclasses. See Javadoc and existing implementations for detail. Issue: SPR-8354
-
由 Chris Beams 提交于
AbstractEnvironment and subclasses now register a reserved default profile named literally 'default' such that with no action on the part of the user, beans defined against the 'default' profile will be registered - if no other profiles are explicitly activated. For example, given the following three files a.xml, b.xml and c.xml: a.xml ----- <beans> <!-- no 'profile' attribute --> <bean id="a" class="com.acme.A"/> </beans> b.xml ----- <beans profile="default"> <bean id="b" class="com.acme.B"/> </beans> c.xml ----- <beans profile="custom"> <bean id="c" class="com.acme.C"/> </beans> bootstrapping all of the files in a Spring ApplicationContext as follows will result in beans 'a' and 'b', but not 'c' being registered: ApplicationContext ctx = new GenericXmlApplicationContext(); ctx.load("a.xml"); ctx.load("b.xml"); ctx.load("c.xml"); ctx.refresh(); ctx.containsBean("a"); // true ctx.containsBean("b"); // true ctx.containsBean("c"); // false whereas activating the 'custom' profile will result in beans 'a' and 'c', but not 'b' being registered: ApplicationContext ctx = new GenericXmlApplicationContext(); ctx.load("a.xml"); ctx.load("b.xml"); ctx.load("c.xml"); ctx.getEnvironment().setActiveProfiles("custom"); ctx.refresh(); ctx.containsBean("a"); // true ctx.containsBean("b"); // false ctx.containsBean("c"); // true that is, once the 'custom' profile is activated, beans defined against the the reserved default profile are no longer registered. Beans not defined against any profile ('a') are always registered regardless of which profiles are active, and of course beans registered against specific active profiles ('c') are registered. The reserved default profile is, in practice, just another 'default profile', as might be added through calling env.setDefaultProfiles() or via the 'spring.profiles.default' property. The only difference is that the reserved default is added automatically by AbstractEnvironment implementations. As such, any call to setDefaultProfiles() or value set for the 'spring.profiles.default' will override the reserved default profile. If a user wishes to add their own default profile while keeping the reserved default profile as well, it will need to be explicitly redeclared, e.g.: env.addDefaultProfiles("my-default-profile", "default") The reserved default profile(s) are determined by the value returned from AbstractEnvironment#getReservedDefaultProfiles(). This protected method may be overridden by subclasses in order to customize the set of reserved default profiles. Issue: SPR-8203
-
由 Chris Beams 提交于
Method is obsolete now that Environment (thus AbstractEnvironment as well) implements the ConfigurablePropertyResolver interface.
-
由 Chris Beams 提交于
-
由 Rossen Stoyanchev 提交于
-
- 19 5月, 2011 6 次提交
-
-
由 Arjen Poutsma 提交于
-
由 Arjen Poutsma 提交于
-
由 Rossen Stoyanchev 提交于
-
由 Rossen Stoyanchev 提交于
-
由 Costin Leau 提交于
- removed generics from Cache/CacheManager (they add no value since it's an SPI not API) + update docs and tests + renamed ConcurrentCacheFactoryBean to ConcurrentMapCacheFactoryBean
-
由 Costin Leau 提交于
- removed AbstractDelegatingCache (a cache is not a map, no need to offer a template) + renamed ConcurrentCache to ConcurrentCacheMap
-
- 18 5月, 2011 10 次提交
-
-
由 Arjen Poutsma 提交于
-
由 Arjen Poutsma 提交于
-
由 Chris Beams 提交于
Revert signature of ConfigurationClassPostProcessor#processConfigBeanDefinitions to its form found in the 3.0.x line. Refactorings made during 3.1 development caused otherwise package-private types such as ConfigurationClassBeanDefinitionReader to escape through this public method, causing issues for STS as well as being a general design issue. Upon review, the refactorings could easily be backed out in favor of a simpler approach, and this has been done. This also means that ConfigurationClassBeanDefinitionReader can return to package-private visibility, and this change has been made as well. Issue: SPR-8200
-
由 Chris Beams 提交于
Issue: SPR-8200
-
由 Costin Leau 提交于
+ update failing test
-
由 Costin Leau 提交于
+ update failing test
-
由 Costin Leau 提交于
+ update failing AJ test
-
由 Costin Leau 提交于
+ update failing test
-
由 Costin Leau 提交于
+ add missing files (remember to check "show unversioned files")
-
由 Costin Leau 提交于
- eliminate unneeded methods + introduced value wrapper (name still to be decided) to avoid cache race conditions + improved name consistency
-
- 17 5月, 2011 2 次提交
-
-
由 Rossen Stoyanchev 提交于
-
由 Arjen Poutsma 提交于
-