- 11 9月, 2012 2 次提交
-
-
由 Chris Beams 提交于
Class#getDeclaredMembers returns arbitrary results under JDK7. This results in non-deterministic execution of JUnit test methods, often revealing unintended dependencies between methods that rely on a specific order to succeed. JUnit 4.11 contains support for predictable test ordering [1], but at the time of this commit, JUnit 4.11 has not yet been released. Therefore we are testing against a snapshot version [2], which has been uploaded to repo.springsource.org [3] for easy access. Note that this artifact may be removed when JUnit 4.11 goes GA. - Care has been taken to ensure that spring-test's compile-time dependency on JUnit remains at 4.10. This means that the spring-test pom.xml will continue to have an optional <dependency> on JUnit 4.10, instead of the 4.11 snapshot. - For reasons not fully understood, the upgrade to the 4.11 snapshot of junit-dep caused NoSuchMethodErrors around certain Hamcrest types, particularly CoreMatchers and Matchers. import statements have been updated accordingly throughout affected test cases. - Runtime errors also occurred around uses of JUnit @Rule and ExpectedException. These have been reverted to use simpler mechanisms like @test(expected) in the meantime. - Some test methods with order-based dependencies on one another have been renamed in order to fall in line with JUnit 4.11's new method ordering (as opposed to actually fixing the inter-test dependencies). In other areas, the fix was as simple as adding a tearDown method and cleaning up state. - For no apparent reason, the timeout in AspectJAutoProxyCreatorTests' testAspectsAndAdvisorNotAppliedToPrototypeIsFastEnough method begins to be exceeded. Prior to this commit the timeout value was 3000 ms; on the CI server under Linux/JDK6 and JDK7, the test begins taking anywhere from 3500-5500 ms with this commit. It is presumed that this is an incidental artifact of the upgrade to JUnit 4.11. In any case, there are no changes to src/main in this commit, so this should not actually represent a performance risk for Spring Framework users. The timeout has been increased to 6000 ms to accommodate this situation. [1]: https://github.com/KentBeck/junit/pull/293 [2]: https://github.com/downloads/KentBeck/junit/junit-dep-4.11-SNAPSHOT-20120805-1225.jar [3]: https://repo.springsource.org/simple/ext-release-local/junit/junit-dep/4.11.20120805.1225 Issue: SPR-9783
-
由 Juergen Hoeller 提交于
-
- 10 9月, 2012 2 次提交
-
-
由 Juergen Hoeller 提交于
Issue: SPR-9754
-
由 Arjen Poutsma 提交于
-
- 07 9月, 2012 1 次提交
-
-
由 Arjen Poutsma 提交于
-
- 06 9月, 2012 2 次提交
-
-
由 Phillip Webb 提交于
Update the ReflectiveAspectJAdvisorFactory class to sort candidate AOP methods based on their annotation first and method name second. Prior to this the order of aspects created from annotated methods could differ depending on the underling JVM, as first noticed under JDK7 in SPR-9729. - ConvertingComparator and InstanceComparator have been introduced in support of this change, per SPR-9730. - A shared static INSTANCE field has been added to ComparableComparator to avoid unnecessary instantiation costs within ConvertingComparator as well as to prevent generics warnings during certain caller scenarios. Issue: SPR-9729, SPR-9730
-
由 Phillip Webb 提交于
-
- 05 9月, 2012 1 次提交
-
-
由 Juergen Hoeller 提交于
-
- 23 8月, 2012 1 次提交
-
-
由 Arjen Poutsma 提交于
This change makes it possible to use the RestTemplate to read an HTTP response into a target generic type object. The RestTemplate has three new exchange(...) methods that accept ParameterizedTypeReference -- a new class that enables capturing and passing generic type info. See the Javadoc of the three new methods in RestOperations for a short example. To support this feature, the HttpMessageConverter is now extended by GenericHttpMessageConverter, which adds a method for reading an HttpInputMessage to a specific generic type. The new interface is implemented by the MappingJacksonHttpMessageConverter and also by a new Jaxb2CollectionHttpMessageConverter that can read read a generic Collection where the generic type is a JAXB type annotated with @XmlRootElement or @XmlType. Issue: SPR-7023
-
- 06 8月, 2012 1 次提交
-
-
由 Sam Brannen 提交于
- renamed resolveParameterizedReturnType() to resolveReturnTypeForGenericMethod() - fleshed out Javadoc for resolveReturnType() and resolveReturnTypeForGenericMethod() regarding declaration of formal type variables - improved wording in log statements and naming of local variables within resolveReturnTypeForGenericMethod() Issue: SPR-9493
-
- 29 7月, 2012 1 次提交
-
-
由 Sam Brannen 提交于
For legacy reasons, a MockEnvironment implementation already exists in multiple places within Spring's test suite; however, it is not available to the general public. This commit promotes MockEnvironment to a first-class citizen in the spring-test module, alongside the existing MockPropertySource. In addition, the following house cleaning has been performed. - deleted MockPropertySource from the spring-expression module - deleted MockEnvironment from the "spring" integration testing module - updated test copies of MockPropertySource and MockEnvironment - documented MockEnvironment and MockPropertySource in the testing chapter of the reference manual Issue: SPR-9492
-
- 06 7月, 2012 1 次提交
-
-
由 Chris Beams 提交于
Prior to this change, PropertySourcesPropertyResolver (and therefore all AbstractEnvironment) implementations failed to resolve nested placeholders as in the following example: p1=v1 p2=v2 p3=${v1}:{$v2} Calls to PropertySource#getProperty for keys 'p1' and 'v1' would successfully return their respective values, but for 'p3' the return value would be the unresolved placeholders. This behavior is inconsistent with that of PropertyPlaceholderConfigurer. PropertySourcesPropertyResolver #getProperty variants now resolve any nested placeholders recursively, throwing IllegalArgumentException for any unresolvable placeholders (as is the default behavior for PropertyPlaceholderConfigurer). See SPR-9569 for an enhancement that will intoduce an 'ignoreUnresolvablePlaceholders' switch to make this behavior configurable. This commit also improves error output in PropertyPlaceholderHelper#parseStringValue by including the original string in which an unresolvable placeholder was found. Issue: SPR-9473, SPR-9569
-
- 20 6月, 2012 1 次提交
-
-
由 Sam Brannen 提交于
Currently, if a factory method is parameterized and the corresponding variable types are declared on the method itself instead of on the enclosing class or interface, Spring always predicts the return type to be Object, even if the return type can be explicitly inferred from the method signature and supplied arguments (which are available in the bean definition). This commit introduces a new resolveParameterizedReturnType() method in GenericTypeResolver that attempts to infer the concrete type for the generic return type of a given parameterized method, falling back to the standard return type if necessary. Furthermore, AbstractAutowireCapableBeanFactory now delegates to resolveParameterizedReturnType() when predicting the return type for factory methods. resolveParameterizedReturnType() is capable of inferring the concrete type for return type T for method signatures similar to the following. Such methods may potentially be static. Also, the formal argument list for such methods is not limited to a single argument. - public <T> T foo(Class<T> clazz) - public <T> T foo(Object obj, Class<T> clazz) - public <V, T> T foo(V obj, Class<T> clazz) - public <T> T foo(T obj) Issue: SPR-9493
-
- 14 6月, 2012 1 次提交
-
-
由 Dave Syer 提交于
This turns out not to be the main problem exposed in SPR-9498 but it seems like a sensible addition anyway.
-
- 28 5月, 2012 1 次提交
-
-
由 Chris Beams 提交于
Avoid Eclipse classpath conflicts between test versions of @Qualified and @Autowired living in spring-core and actual versions living in spring-beans.
-
- 27 5月, 2012 1 次提交
-
-
由 Chris Beams 提交于
The following syntax is now supported <beans profile="p1,!p2"> @Profile("p1", "!p2") indicating that the <beans> element or annotated component should be processed only if profile 'p1' is active or profile 'p2' is not active. Issue: SPR-8728
-
- 26 5月, 2012 2 次提交
-
-
由 Chris Beams 提交于
Prior to this change, AbstractApplicationContext#setParent replaced the child context's Environment with the parent's Environment if available. This has the negative effect of potentially changing the type of the child context's Environment, and in any case causes property sources added directly against the child environment to be ignored. This situation could easily occur if a WebApplicationContext child had a non-web ApplicationContext set as its parent. In this case the parent Environment type would (likely) be StandardEnvironment, while the child Environment type would (likely) be StandardServletEnvironment. By directly inheriting the parent environment, critical property sources such as ServletContextPropertySource are lost entirely. This commit introduces the concept of merging an environment through the new ConfigurableEnvironment#merge method. Instead of replacing the child's environment with the parent's, AbstractApplicationContext#setParent now merges property sources as well as active and default profile names from the parent into the child. In this way, distinct environment objects are maintained with specific types and property sources preserved. See #merge Javadoc for additional details. Issue: SPR-9444, SPR-9439
-
由 Chris Beams 提交于
Issue: SPR-9439
-
- 17 5月, 2012 5 次提交
-
-
由 Stevo Slavic 提交于
A set of resolved placeholder references is used for circular placeholder prevention. For complex property definitions this mechanism would put property values with unresolved inner placeholder references in the set, but would try to remove property values with placeholders resolved, leaving the set in an invalid state and the mechanism broken. This fix makes sure that the value that is put in the set is same one that is removed from it, and by doing so avoids false positives in reporting circular placeholders. Issue: SPR-5369
-
由 Chris Beams 提交于
-
由 Stevo Slavic 提交于
Even though the Javadoc for Constants#toCode and #toCodeForSuffix specifies that a null value for the 'namePrefix' and 'nameSuffix' parameters are respectively allowed, before this change passing a null to either would result in a NullPointerException. This change fixes constant name lookup for null values of these params as if an empty string had been passed instead. This way of handling a null value is consistent with the rest of Constants class API. Issue: SPR-8278
-
由 Chris Beams 提交于
Previously, StringUtils#parseLocaleString would parse locale strings having the same lowercase token for both language and country incorrectly, e.g. 'tr_tr' would parse to 'tr_TR_tr' as opposed to the expected 'tr_TR'. This commit fixes this behavior by using using String#lastIndexOf instead of String#indexOf when determining the location of the country code token. Issue: SPR-9420
-
由 Petr Janecek 提交于
In AnnotationUtils#findAnnotation(Method, Class), the search for a method annotation fails if: - the original method does not have the annotation - an abstract superclass does not have an equivalent method declared - an interface implemented by the superclass has the method and the annotation -> this should be found, but is not! This happens because the try-catch block in #findAnnotation is too wide: cl.getDeclaredMethod() can throw NoSuchMethodException and skip the '#searchOnInterfaces' call prematurely. The try-catch block was made narrower to allow #searchOnInterfaces to be called even if the abstract class does not have the method declared at all. Issue: SPR-9342
-
- 16 5月, 2012 2 次提交
-
-
由 Nikita Tovstoles 提交于
Prior to this change, Spring's MethodParameter#getParameterAnnotations called java.lang.Method#getParameterAnnotations on every invocation. The latter ends up contending for a monitor inside (Sun) JDK code. This is problematic when dealing with the high number of @RequestMapping invocations that can occur in a Spring MVC @Controller. This commit eliminates this contention by caching values returned by java.lang.Method#getParameterAnnotations in a static ConcurrentMap. Note that only Method parameter annotations are cached, while Constructor parameter annotations are not. This is because the issue of primary concern is, as mentioned above, @RequestMapping methods. By nature, constructors are called much more infrequently, and in most cases in a single-threaded fashion. Issue: SPR-9298
-
由 Sam Brannen 提交于
ClassPathResource.getDescription() now returns consistent, meaningful results for all variants of ClassPathResource's constructors. Issue: SPR-9413
-
- 03 4月, 2012 1 次提交
-
-
由 Rossen Stoyanchev 提交于
Issues: SPR-7970
-
- 29 2月, 2012 1 次提交
-
-
由 Chris Beams 提交于
Prior to this commit, MutablePropertySources#get(String) would throw IndexArrayOutOfBoundsException if the named property source does not actually exist. This is a violation of the PropertySource#get contract as described in its Javadoc. The implementation now correctly checks for the existence of the named property source, returning null if non-existent and otherwise returning the associated PropertySource. Other changes - Rename PropertySourcesTests => MutablePropertySourcesTests - Polish MutablePropertySourcesTests for style, formatting - Refactor MutablePropertySources for consistency Issue: SPR-9179
-
- 24 2月, 2012 1 次提交
-
-
由 Chris Beams 提交于
Due to changes made in commit 2fa87a71 for SPR-9118, AbstractResource#contentLength would fall into an infinite loop unless the method were overridden by a subclass (which it is in the majority of use cases). This commit: - fixes the infinite recursion by refactoring to a while loop - asserts that the value returned from #getInputStream is not null in order to avoid NullPointerException - tests both of the above - adds Javadoc to the Resource interface to clearly document that the contract for any implementation is that #getInputStream must not return null Issue: SPR-9161
-
- 31 1月, 2012 1 次提交
-
-
由 Chris Beams 提交于
This renaming more intuitively expresses the relationship between subprojects and the JAR artifacts they produce. Tracking history across these renames is possible, but it requires use of the --follow flag to `git log`, for example $ git log spring-aop/src/main/java/org/springframework/aop/Advisor.java will show history up until the renaming event, where $ git log --follow spring-aop/src/main/java/org/springframework/aop/Advisor.java will show history for all changes to the file, before and after the renaming. See http://chrisbeams.com/git-diff-across-renamed-directories
-