- 26 10月, 2010 1 次提交
-
-
由 Chris Beams 提交于
Branch in question is 'env' branch from git://git.springsource.org/sandbox/cbeams.git; merged into git-svn repository with: git merge -s recursive -Xtheirs --no-commit env No merge conflicts, but did need to git rm spring-build prior to committing. With this change, Spring 3.1.0 development is now happening on SVN trunk. Further commits to the 3.0.x line will happen in an as-yet uncreated SVN branch. 3.1.0 snapshots will be available per the usual nightly CI build from trunk.
-
- 08 9月, 2010 1 次提交
-
-
由 Chris Beams 提交于
Before: - new GenericXmlApplicationContext("com/acme/path/to/resource.xml"); - GenericXmlApplicationContext ctx = new GenericXmlApplicationContext(); ctx.load("com/acme/path/to/resource.xml"); ctx.refresh(); After: - The above remain supported, as well as new class-relative variants - import com.acme.path.to.Foo; new GenericXmlApplicationContext(Foo.class, "resource.xml"); - import com.acme.path.to.Foo; GenericXmlApplicationContext ctx = new GenericXmlApplicationContext(); ctx.load(Foo.class, "resource.xml"); ctx.refresh(); These changes are generally aligned with signatures long available in ClassPathXmlApplicationContext. As GenericXmlApplicationContext is intended to be a more flexible successor to CPXAC (and FSXAC), it's important that all the same conveniences are available.
-
- 07 9月, 2010 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 27 8月, 2010 1 次提交
-
-
由 Chris Beams 提交于
GenericApplicationContext and AbstractRefreshableApplicationContext implementations now call DefaultListableBeanFactory.setSerializationId() only upon successful refresh() instead of on instantiation of the context, as was previously the case with GAC. DLBF.setSerializationId() adds the beanFactory to the *static* DLBF.serializableFactories map, and while calling close() on the application context removes entries from that map, it does so only if the context is currently active (i.e. refresh() has been called). Also, cancelRefresh() has been overridden in GAC just as it has been in ARAC to accomodate the possibility of a BeansException being thrown. In this case, the beanFactory serializationId will be nulled out and the beanFactory removed from the serializableFactories map. The SerializableBeanFactoryMemoryLeakTests test case provides full coverage of these scenarios.
-
- 16 8月, 2010 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 14 8月, 2010 1 次提交
-
-
由 David Syer 提交于
-
- 21 7月, 2010 2 次提交
-
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
JSR-303 Pattern message resolvable through Spring MessageSource (despite special characters; SPR-7329)
-
- 08 6月, 2010 2 次提交
-
-
由 Juergen Hoeller 提交于
revised DefaultLifecycleProcessor's handling of circular dependencies to avoid stack overflow (SPR-7266)
-
由 Juergen Hoeller 提交于
-
- 20 5月, 2010 1 次提交
-
-
由 Juergen Hoeller 提交于
refined LifecycleProcessor exception handling, properly wrapping a start exception from a bean (SPR-7106)
-
- 18 5月, 2010 2 次提交
-
-
由 Juergen Hoeller 提交于
-
由 Chris Beams 提交于
BeanDefinitionRegistryPostProcessors' postProcessBeanDefinitionRegistry() method now gets called before postProcessBeanFactory() (SPR-7167)
-
- 04 3月, 2010 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 16 2月, 2010 1 次提交
-
-
由 Juergen Hoeller 提交于
BeanDefinitionReader and ClassPath/FileSystemXmlApplicationContext use varargs where possible (SPR-6849)
-
- 15 2月, 2010 1 次提交
-
-
由 Juergen Hoeller 提交于
context-specific "conversionService" bean may refer to annotation-configured converter beans (SPR-6800)
-
- 10 2月, 2010 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 04 2月, 2010 4 次提交
-
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
ApplicationListeners will get detected lazily as well (e.g. on @Bean's concrete result); inner bean ApplicationListeners will be invoked through their proxy (if any)
-
- 31 1月, 2010 2 次提交
-
-
由 Juergen Hoeller 提交于
refined DefaultLifecycleProcessor's start/stop logging and stop exception handling (SPR-6769, SPR-6770)
-
由 Juergen Hoeller 提交于
introduced BeanDefinitionRegistryPostProcessor extension to BeanFactoryPostProcessor; @Configuration classes support definition of BeanFactoryPostProcessor beans as well (SPR-6455, SPR-6611)
-
- 22 1月, 2010 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 08 1月, 2010 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 07 1月, 2010 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 14 12月, 2009 1 次提交
-
-
由 Juergen Hoeller 提交于
removed getBeansWithAnnotation(Class,boolean,boolean) method from ListableBeanFactory; reimplemented getBeansWithAnnotation(Class) to avoid use of getBeanNamesForType(Object.class)
-
- 13 12月, 2009 3 次提交
-
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
-
- 10 12月, 2009 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 09 12月, 2009 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 08 12月, 2009 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 28 11月, 2009 2 次提交
-
-
由 Mark Fisher 提交于
-
由 Mark Fisher 提交于
SPR-5507 When determining start/stop order, the DefaultLifecycleProcessor checks for the new Phased interface rather than SmartLifecycle now.
-
- 25 11月, 2009 2 次提交
-
-
由 Juergen Hoeller 提交于
fixed LifecycleProcessor lookup in a Spring Dynamic Modules context (SPR-6356); moved ConversionService lookup to prepareBeanFactory
-
由 Mark Fisher 提交于
SPR-5507 The 'shutdownOrder' property of SmartLifecycle has been renamed 'phase'. The order no longer applies to shutdown only; now startup order is determined by the phase value as well. Components start in ascending order and stop in descending order.
-
- 22 11月, 2009 1 次提交
-
-
由 Keith Donald 提交于
-
- 21 11月, 2009 1 次提交
-
-
由 Mark Fisher 提交于
SPR-6354 DefaultLifecycleProcessor no longer waits for the shutdown of SmartLifecycle beans that are not actually running.
-
- 20 11月, 2009 1 次提交
-
-
由 Keith Donald 提交于
-