- 16 11月, 2011 2 次提交
-
-
由 Chris Beams 提交于
-
由 Chris Beams 提交于
-
- 10 11月, 2011 1 次提交
-
-
由 Costin Leau 提交于
SPR-8082 SPR-7833 + add support for CacheDefinitions declarations inside XML + more integration tests
-
- 09 11月, 2011 3 次提交
-
-
由 Costin Leau 提交于
-
由 Costin Leau 提交于
-
由 Costin Leau 提交于
+ introduced @CacheDefinition annotation + introduced meta-annotation to allow multiple @cache annotations SPR-7833 SPR-8082
-
- 12 10月, 2011 3 次提交
-
-
由 Chris Beams 提交于
Anywhere the value of a destroy method may be expressed, specifying the value "(inferred)" now indicates that the container should attempt to automatically discover a destroy method. This functionality is currently limited to detecting public, no-arg methods named 'close'; this is particularly useful for commonly used types such as Hibernate SessionFactory most JDBC DataSource implementations, JMS connection factories, and so forth. This special value is captured as the constant AbstractBeanDefinition#INFER_METHOD, which in turn serves as the default value of the @Bean#destroyMethod attribute. For example in the following case @Bean public BasicDataSource dataSource() { ... } the container will automatically detect BasicDataSource#close and invoke it when the enclosing ApplicationContext is closed. This is exactly equivalent to @Bean(destroyMethod="(inferred)") public BasicDataSource dataSource() { ... } A user may override this inference-by-default convention simply by specifying a different method @Bean(destroyMethod="myClose") public MyBasicDataSource dataSource() { ... } or, in the case of a bean that has an otherwise inferrable 'close' method, but the user wishes to disable handling it entirely, an empty string may be specified @Bean(destroyMethod="") public MyBasicDataSource dataSource() { ... } The special destroy method name "(inferred)" may also be specified in an XML context, e.g. <bean destroy-method="(inferred)"> or <beans default-destroy-method="(inferred)"> Note that "(inferred)" is the default value for @Bean#destroyMethod, but NOT for the destroy-method and default-destroy-method attributes in the spring-beans XML schema. The principal reason for introducing this feature is to avoid forcing @Configuration class users to type destroyMethod="close" every time a closeable bean is configured. This kind of boilerplate is easily forgotten, and this simple convention means the right thing is done by default, while allowing the user full control over customization or disablement in special cases. Issue: SPR-8751
-
由 Chris Beams 提交于
Issue: SPR-8138
-
由 Juergen Hoeller 提交于
-
- 11 10月, 2011 1 次提交
-
-
由 Chris Beams 提交于
Reproduces the issue described in SPR-8756 in addition to demonstrating the suggested workaround. Issue: SPR-8756, SPR-8725
-
- 10 10月, 2011 1 次提交
-
-
由 Chris Beams 提交于
Add BridgeMethodResolver#isJava6VisibilityBridgeMethodPair to distinguish between (a) bridge methods introduced in Java 6 to compensate for inheriting public methods from non-public superclasses and (b) bridge methods that have existed since Java 5 to accommodate return type covariance and generic parameters. In the former case, annotations should be looked up from the original bridged method (SPR-7900). In the latter, the annotation should be looked up against the bridge method itself (SPR-8660). As noted in the Javadoc for the new method, see http://stas-blogspot.blogspot.com/2010/03/java-bridge-methods-explained.html for a useful description of the various types of bridge methods, as well as http://bugs.sun.com/view_bug.do?bug_id=6342411, the bug fixed in Java 6 resulting in the introduction of 'visibility bridge methods'. Issue: SPR-8660, SPR-7900
-
- 09 10月, 2011 1 次提交
-
-
由 Chris Beams 提交于
-
- 08 10月, 2011 2 次提交
-
-
由 Costin Leau 提交于
+ more tests
-
由 Costin Leau 提交于
+ expose key-generator in the XML namespace
-
- 27 9月, 2011 5 次提交
-
-
由 Sam Brannen 提交于
-
由 Rossen Stoyanchev 提交于
-
由 Sam Brannen 提交于
[SPR-8178] @Ignore-ing testPrintNull() until it is determined why changes to GenericConversionService broke this test.
-
由 Sam Brannen 提交于
-
由 Sam Brannen 提交于
[SPR-8178] @Ignore-ing testDefaultNumberFormatting() until it is determined why changes to GenericConversionService broke this test.
-
- 04 9月, 2011 1 次提交
-
-
由 Chris Beams 提交于
Issue: SPR-8643
-
- 02 9月, 2011 1 次提交
-
-
由 Costin Leau 提交于
+ refactor a bit the internals of CacheAspect to allow invocations that do not throw any exceptions (AspectJ)
-
- 20 8月, 2011 1 次提交
-
-
由 Chris Beams 提交于
Prior to this change, StandardServletEnvironment evaluated a "jndiPropertySourceEnabled" flag to determine whether or not to add a JndiPropertySource. Following the changes introduced in SPR-8490, there is now no reason not to enable a JNDI property source by default. This change eliminates the support for "jndiPropertySourceEnabled" and adds a JndiPropertySource automatically. Issue: SPR-8545, SPR-8490
-
- 19 8月, 2011 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 18 8月, 2011 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 17 8月, 2011 1 次提交
-
-
由 Costin Leau 提交于
-
- 13 8月, 2011 1 次提交
-
-
由 Sam Brannen 提交于
-
- 12 8月, 2011 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 27 7月, 2011 2 次提交
-
-
由 Chris Beams 提交于
-
由 Chris Beams 提交于
-
- 22 7月, 2011 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 20 7月, 2011 1 次提交
-
-
由 Chris Beams 提交于
A <scheduled:task> element declared within a <beans default-lazy-init="true"> element represents a contradiction in terms: such a task will never be executed. For this reason, we now override any inherited lazy-init settings when parsing <scheduled:task> elements, forcing lazy-init to false for the underlying ScheduledTaskRegistrar bean. Thanks to Mike Youngstrom for contributing an initial patch. Issue: SPR-8498
-
- 14 7月, 2011 1 次提交
-
-
由 Chris Beams 提交于
Prior to this change, an instance of ConfigurationClassPostProcessor would throw IllegalStateException if its postProcessBeanDefinitionRegistry method were called more than once. This check is important to ensure that @Configuration classes are not proxied by CGLIB multiple times, and works for most normal use cases. However, if the same CCPP instance is used to process multiple registries/factories/contexts, this check creates a false negative because it does not distinguish between invocations of postProcessBeanDefinitionRegistry across different registries. A use case for this, though admittedly uncommon, would be creating a CCPP instance and registering it via ConfigurableApplicationContext#addBeanDefinitionPostProcessor against several ApplicationContexts. In such a case, the same CCPP instance will post-process multiple different registry instances, and throw the above mentioned exception. With this change, CCPP now performs lightweight tracking of the registries/beanFactories that it has already processed by recording the identity hashcodes of these objects. This is only slightly more complex than the previous boolean-based 'already processed' flags, and prevents this issue (however rare it may be) from occurring. Issue: SPR-8527
-
- 06 7月, 2011 3 次提交
-
-
由 Chris Beams 提交于
For the particular use case detailed in SPR-8514, with this change we now attempt to determine the object type of a FactoryBean through its generic type parameter if possible. For (a contrived) example: @Configuration public MyConfig { @Bean public FactoryBean<String> fb() { return new StringFactoryBean("foo"); } } The implementation will now look at the <String> generic parameter instead of attempting to instantiate the FactoryBean in order to call its #getObjectType() method. This is important in order to avoid the autowiring lifecycle issues detailed in SPR-8514. For example, prior to this change, the following code would fail: @Configuration public MyConfig { @Autowired Foo foo; @Bean public FactoryBean<String> fb() { Assert.notNull(foo); return new StringFactoryBean("foo"); } } The reason for this failure is that in order to perform autowiring, the container must first determine the object type of all configured FactoryBeans. Clearly a chicken-and-egg issue, now fixed by this change. And lest this be thought of as an obscure bug, keep in mind the use case of our own JPA support: in order to configure and return a LocalContainerEntityManagerFactoryBean from a @Bean method, one will need access to a DataSource, etc -- resources that are likely to be @Autowired across @Configuration classes for modularity purposes. Note that while the examples above feature methods with return types dealing directly with the FactoryBean interface, of course the implementation deals with subclasses/subinterfaces of FactoryBean equally as well. See ConfigurationWithFactoryBeanAndAutowiringTests for complete examples. There is at least a slight risk here, in that the signature of a FactoryBean-returing @Bean method may advertise a generic type for the FactoryBean less specific than the actual object returned (or than advertised by #getObjectType for that matter). This could mean that an autowiring target may be missed, that we end up with a kind of autowiring 'false negative' where FactoryBeans are concerned. This is probably a less common scenario than the need to work with an autowired field within a FactoryBean-returning @Bean method, and also has a clear workaround of making the generic return type more specific. Issue: SPR-8514
-
由 Chris Beams 提交于
isCglibProxy* methods in AopUtils are useful in lower-level modules, i.e. those that cannot depend on .aop. Therefore copied these methods to ClassUtils; deprecated the existing ones in AopUtils and now delegating to the new location; switched all usage of AopUtils#isCglibProxy* within the framework to use ClassUtils#isCglibProxy* instead.
-
由 Chris Beams 提交于
Even after applying @Ignore to these tests at the class level, they still run (and fail) under ant when the jmxremote_optional jar is not present. See the issues mentioned below for information on how these tests will be re-enabled. Issue: SPR-8089, SPR-8093, SPR-8458
-
- 04 7月, 2011 2 次提交
-
-
由 Juergen Hoeller 提交于
-
由 Juergen Hoeller 提交于
-
- 03 7月, 2011 1 次提交
-
-
由 Chris Beams 提交于
Prior to this change, JndiPropertySource worked directly against a JNDI Context instance as its 'source' object. This works well enough, but is not nearly as fully-featured as Spring's existing JndiLocatorDelegate. This change refactors JndiPropertySource from relying on an underlying Context to relying on an underlying JndiLocatorDelegate. By default, the delegate's "resourceRef" property is set to true, meaning that the implementation will always try to prepand a given name with "java:comp/env/" before looking up the name, and upon failure will drop back to the given name sans prefix. See JndiPropertySource Javadoc for complete details. Issue: SPR-8490
-
- 01 7月, 2011 1 次提交
-
-
由 Costin Leau 提交于
+ add no-op cache implementations suitable for cache declarations w/o a backing store
-
- 25 6月, 2011 1 次提交
-
-
由 David Syer 提交于
* Changes to ASpectJExpressionPointcut plus some tests in Spring AOP * plus some tests in groovy support
-