GitHub-Spring/spring-framework - spring-framework - Gitea: Git with a cup of tea

Author	SHA1	Message	Date
Juergen Hoeller	6078c27e60	Fixed evaluation of "!" operator in case of multiple profile expressions Issue: SPR-11093	12 years ago
Juergen Hoeller	614387fe0e	Sneaked in test for covariant return type narrowing in a getter method Issue: SPR-10995	12 years ago
Chris Beams	3100d89d07	Clean up console output for spring-beans tests	13 years ago
Chris Beams	42729014b6	Move namespace tests to root integration module Prior to this change, spring-beans contained its own META-INF containing spring.handlers and spring.schemas files in src/main/resources; it also had files of the same name within src/test/resources/META-INF, causing 'duplicate resource' warnings and confusion in general. This commit moves the com.foo test package, it's associated namespace parsing tests and test versions of META-INF files to the root project and it's src/test integration testing folder. Issue: SPR-9431	13 years ago
Phillip Webb	42b5d6dd7e	Remove duplicate test classes Prior to this commit many test utility classes and sample beans were duplicated across projects. This was previously necessary due to the fact that dependent test sources were not shared during a gradle build. Since the introduction of the 'test-source-set-dependencies' gradle plugin this is no longer the case. This commit attempts to remove as much duplicate code as possible, co-locating test utilities and beans in the most suitable project. For example, test beans are now located in the 'spring-beans' project. Some of the duplicated code had started to drift apart when modifications made in one project where not ported to others. All changes have now been consolidated and when necessary existing tests have been refactored to account for the differences. Conflicts: spring-beans/src/test/java/org/springframework/beans/factory/ConcurrentBeanFactoryTests.java spring-beans/src/test/java/org/springframework/beans/factory/support/BeanFactoryGenericsTests.java spring-beans/src/test/java/org/springframework/beans/support/PagedListHolderTests.java	13 years ago
Chris Beams	5bcf68e25a	Use ExtendedBeanInfo on an as-needed basis only Prior to this change, CachedIntrospectionResults delegated to ExtendedBeanInfo by default in order to inspect JavaBean PropertyDescriptor information for bean classes. Originally introduced with SPR-8079, ExtendedBeanInfo was designed to go beyond the capabilities of the default JavaBeans Introspector in order to support non-void returning setter methods, principally to support use of builder-style APIs within Spring XML. This is a complex affair, and the non-trivial logic in ExtendedBeanInfo has led to various bugs including regressions for bean classes that do not declare non-void returning setters. This commit takes advantage of the new BeanInfoFactory mechanism introduced in SPR-9677 to take ExtendedBeanInfo out of the default code path for CachedIntrospectionResults. Now, the new ExtendedBeanInfoFactory class will be detected and instantiated (per its entry in the META-INF/spring.beanInfoFactories properties file shipped with the spring-beans jar). ExtendedBeanInfoFactory#supports is invoked for all bean classes in order to determine whether they are candidates for ExtendedBeanInfo introspection, i.e. whether they declare non-void returning setter methods. If a class does not declare any such non-standard setter methods (the 99% case), then CachedIntrospectionResults will fall back to the default JavaBeans Introspector. While efforts have been made to fix any bugs with ExtendedBeanInfo, this change means that EBI will not pose any future risk for bean classes that do not declare non-standard setter methods, and also means greater efficiency in general. Issue: SPR-9723, SPR-9677, SPR-8079	14 years ago
Arjen Poutsma	ca017a4880	Introduce strategy for BeanInfo creation Before this commit, the CachedIntrospectionResults was hard-coded to create ExtendedBeanInfos for bean classes. The ExtendedBeanInfo support the JavaBeans property contract only. This commit introduces the BeanInfoFactory, a strategy for creating BeanInfos. Through this strategy, it is possible to support beans that do not necessarily implement the JavaBeans contract (i.e. have a different getter or setter style). BeanInfoFactories are are instantiated by the CachedIntrospectionResults, which looks for 'META-INF/spring.beanInfoFactories' files on the class path. These files contain one or more BeanInfoFactory class names. When a BeanInfo is to be created, the CachedIntrospectionResults will iterate through the factories, asking it to create a BeanInfo for the given bean class. If none of the factories support it, an ExtendedBeanInfo is created as a default. This commit also contains a change to Property, allowing BeanWrapperImpl to specify the property name at construction time (as opposed to using Property#resolveName(), which supports the JavaBeans contract only). Issue: SPR-9677	14 years ago
Sam Brannen	c461455c7c	Infer return type of parametrized factory methods 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 years ago
Gary Russell	183ac0c1ff	Add value-type attrib to beans->map->entry element Previously, the <value> subelement of a map <entry> allowed one to specify the type of a specific map entry value. This patch allows a value-type attribute as well, such that instead of the following syntax <entry key="x-message-ttl"> <value type="java.lang.Long">100</value> </entry> <entry key="x-ha-policy" value="all" /> one can now use the more concise form <entry key="x-message-ttl" value="100" value-type="java.lang.Long"/> <entry key="x-ha-policy" value="all"/> The new value-type attribute may be used at the <map> level as well, indicating that all elements are of the same type. Appropriate tests have been added exercising value-type at the <map> and <entry> levels. Issue: SPR-9249	14 years ago
Chris Beams	02a4473c62	Rename modules {org.springframework.=>spring-} 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	14 years ago