Permalink
Commits on Jun 7, 2012
  1. Merge branch '3.1.x' of github.com:SpringSource/spring-framework into…

    … 3.1.x
    Costin Leau committed Jun 7, 2012
Commits on May 27, 2012
  1. preparations for 3.1.2 release

    jhoeller committed May 27, 2012
  2. fixed WindowState comparison

    jhoeller committed May 27, 2012
  3. polishing

    jhoeller committed May 27, 2012
  4. EhCacheFactoryBean applies listeners and enabled/disabled flags to ex…

    …isting cache regions as well (SPR-9392)
    jhoeller committed May 27, 2012
  5. ServletContextResource's getFile implementation falls back to getReal…

    …Path for non-existent files (SPR-8461)
    jhoeller committed May 27, 2012
Commits on May 15, 2012
  1. Add missing section ids in reference documentation

    Add missing id attributes to <section> elements in the reference
    documentation to ensure stable anchor links in HTML output.
    
    Issue: SPR-9410
    Backport-Issue: SPR-9346
    Backport-Commit: 2a75c57
    olivergierke committed with cbeams May 15, 2012
  2. Clarify @EnableScheduling javadoc

    It is now advised that destroyMethod="shutdown" should be used
    on @Bean methods returning an ExecutorService.
    
    Backport-Issue: SPR-9280
    Backport-Commit: 6da03a61b22696283c2c5c79f8f88b5c36480560
    cbeams committed May 14, 2012
Commits on Apr 13, 2012
  1. Fix typo in reference documentation

    Issue: SPR-9321
    cbeams committed Apr 13, 2012
  2. Eliminate INDEX.LIST from Spring jar META-INF dirs

    The contents of this file could be problematic as they were generated
    by spring-build with "org.springframework.core.jar" EBR-style naming,
    but this naming is incorrect when dealing with Maven-central style
    artifacts, e.g. spring-core.jar.
    
    While a well-formed INDEX.LIST may speed up classloading, the simplest
    solution to the issues listed below is simply to eliminate the file.
    This also means consistent treatment across 3.1.x and 3.2.x artifacts,
    as the new Gradle build in 3.2.x does not create these index files.
    
    Issue: SPR-6383, SPR-9208
    cbeams committed Apr 13, 2012
Commits on Mar 14, 2012
  1. JDBC parameter binding uses JDBC 3.0 ParameterMetaData (if available)…

    … for type determination
    jhoeller committed Mar 14, 2012
  2. initial fixes for 3.1.2

    jhoeller committed Mar 14, 2012
  3. JDBC parameter binding uses JDBC 3.0 ParameterMetaData (if available)…

    … for type determination
    jhoeller committed Mar 14, 2012
Commits on Feb 29, 2012
  1. Return null correctly from MutablePropertySources#get

    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-9185
    Backport-Issue: SPR-9179
    Backport-Commit: 15d1d82
    cbeams committed Feb 29, 2012
Commits on Feb 24, 2012
  1. Avoid infinite loop in AbstractResource#contentLength

    Due to changes made in commit 2fa87a7 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-9163
    Backport-Issue: SPR-9161
    Backport-Commit: 7ca5fba
    cbeams committed Feb 24, 2012
Commits on Feb 20, 2012
  1. Fix regression in @PropertySource placeholder resolution

    Changes in commit 41ade68 introduced
    a regression causing all but the first location in the
    @PropertySource#value array to be ignored during ${...} placeholder
    resolution. This change ensures that all locations are processed and
    replaced as expected.
    
    Issue: SPR-9133
    Backport-Issue: SPR-9127
    Backport-Commit: 4df2a14
    cbeams committed Feb 20, 2012
Commits on Feb 17, 2012
Commits on Feb 16, 2012
  1. Warn re Environment construction and instance vars

     - Add warning regarding access to default instance variable values
       during AbstractEnvironment#customizePropertySources callback
    
     - Polish AbstractEnvironment Javadoc and formatting
    
    Issue: SPR-9013
    cbeams committed Feb 16, 2012
  2. Disallow empty @PropertySource(value = {})

    Previously, a user could specify an empty array of resource locations
    to the @PropertySource annotation, which amounts to a meaningless no-op.
    
    ConfigurationClassParser now throws IllegalArgumentException upon
    encountering any such misconfiguration.
    cbeams committed Feb 16, 2012
  3. Fix @PropertySource bug with multiple values

    Prior to this commit, specifying a named @PropertySource with multiple
    values would not work as expected. e.g.:
    
      @PropertySource(
          name = "ps",
          value = { "classpath:a.properties", "classpath:b.properties" })
    
    In this scenario, the implementation would register a.properties with
    the name "ps", and subsequently register b.properties with the name
    "ps", overwriting the entry for a.properties.
    
    To fix this behavior, a CompositePropertySource type has been introduced
    which accepts a single name and a set of PropertySource objects to
    iterate over. ConfigurationClassParser's @PropertySource parsing routine
    has been updated to use this composite approach when necessary, i.e.
    when both an explicit name and more than one location have been
    specified.
    
    Note that if no explicit name is specified, the generated property
    source names are enough to distinguish the instances and avoid
    overwriting each other; this is why the composite wrapper is not used
    in these cases.
    
    Issue: SPR-9127
    cbeams committed Feb 16, 2012
  4. added "receive-timeout" attribute to "jms:listener-container" element…

    … in JMS namespace (SPR-9114)
    jhoeller committed Feb 14, 2012
Commits on Feb 15, 2012
  1. Demonstrate use of @Configuration as meta-annotation

    Issue: SPR-9090
    cbeams committed Feb 15, 2012
  2. Apply @Configuration BeanNameGenerator consistently

    Since the introduction of the AnnotationConfig(Web)ApplicationContext
    types in Spring 3.0, it has been possible to specify a custom
    bean name generation strategy via the #setBeanNameGenerator methods
    available on each of these classes.
    
    If specified, that BeanNameGenerator was delegated to the underlying
    AnnotatedBeanDefinitionReader and ClassPathBeanDefinitionScanner. This
    meant that any @Configuration classes registered or scanned directly
    from the application context, e.g. via #register or #scan methods would
    respect the custom name generation strategy as intended.
    
    However, for @Configuration classes picked up via @Import or implicitly
    registered due to being nested classes would not be aware of this
    strategy, and would rather fall back to a hard-coded default
    AnnotationBeanNameGenerator.
    
    This change ensures consistent application of custom BeanNameGenerator
    strategies in the following ways:
    
     - Introduction of AnnotationConfigUtils#CONFIGURATION_BEAN_NAME_GENERATOR
       singleton
    
       If a custom BeanNameGenerator is specified via #setBeanNameGenerator
       the AnnotationConfig* application contexts will, in addition to
       delegating this object to the underlying reader and scanner, register
       it as a singleton bean within the enclosing bean factory having the
       constant name mentioned above.
    
       ConfigurationClassPostProcessor now checks for the presence of this
       singleton, falling back to a default AnnotationBeanNameGenerator if
       not present. This singleton-based approach is necessary because it is
       otherwise impossible to parameterize CCPP, given that it is
       registered as a BeanDefinitionRegistryPostProcessor bean definition
       in AnnotationConfigUtils#registerAnnotationConfigProcessors
    
     - Introduction of ConfigurationClassPostProcessor#setBeanNameGenerator
    
       As detailed in the Javadoc for this new method, this allows for
       customizing the BeanNameGenerator via XML by dropping down to direct
       registration of CCPP as a <bean> instead of using
       <context:annotation-config> to enable  @Configuration class
       processing.
    
     - Smarter defaulting for @ComponentScan#beanNameGenerator
    
       Previously, @ComponentScan's #beanNameGenerator attribute had a
       default value of AnnotationBeanNameGenerator. The value is now the
       BeanNameGenerator interface itself, indicating that the scanner
       dedicated to processing each @ComponentScan should fall back to an
       inherited generator, i.e. the one originally specified against the
       application context, or the original default provided by
       ConfigurationClassPostProcessor. This means that name generation
       strategies will be consistent with a single point of configuration,
       but that individual @ComponentScan declarations may still customize
       the strategy for the beans that are picked up by that particular
       scanning.
    
    Issue: SPR-9124
    cbeams committed Feb 15, 2012
  3. Improve @Configuration bean name discovery

    Prior to this commit, and based on earlier changes supporting SPR-9023,
    ConfigurationClassBeanDefinitionReader employed a simplistic strategy
    for extracting the 'value' attribute (if any) from @Configuration in
    order to determine the bean name for imported and nested configuration
    classes. An example case follows:
    
      @Configuration("myConfig")
      public class AppConfig { ... }
    
    This approach is too simplistic however, given that it is possible in
    'configuration lite' mode to specify a @Component-annotated class with
    @Bean methods, e.g.
    
      @Component("myConfig")
      public class AppConfig {
          @Bean
          public Foo foo() { ... }
      }
    
    In this case, it's the 'value' attribute of @Component, not
    @Configuration, that should be consulted for the bean name. Or indeed if
    it were any other stereotype annotation meta-annotated with @Component,
    the value attribute should respected.
    
    This kind of sophisticated discovery is exactly what
    AnnotationBeanNameGenerator was designed to do, and
    ConfigurationClassBeanDefinitionReader now uses it in favor of the
    custom approach described above.
    
    To enable this refactoring, nested and imported configuration classes
    are no longer registered as GenericBeanDefinition, but rather as
    AnnotatedGenericBeanDefinition given that AnnotationBeanNameGenerator
    falls back to a generic strategy unless the bean definition in question
    is assignable to AnnotatedBeanDefinition.
    
    A new constructor accepting AnnotationMetadata
    has been added to AnnotatedGenericBeanDefinition in order to support
    the ASM-based approach in use by configuration class processing. Javadoc
    has been updated for both AnnotatedGenericBeanDefinition and its now
    very similar cousin ScannedGenericBeanDefinition to make clear the
    semantics and intention of these two variants.
    
    Issue: SPR-9023
    cbeams committed Feb 15, 2012
  4. Fix infinite recursion bug in nested @Configuration

    Prior to this commit, an infinite recursion would occur if a
    @Configuration class were nested within its superclass, e.g.
    
      abstract class Parent {
          @Configuration
          static class Child extends Parent { ... }
      }
    
    This is because the processing of the nested class automatically
    checks the superclass hierarchy for certain reasons, and each
    superclass is in turn checked for nested @Configuration classes.
    
    The ConfigurationClassParser implementation now prevents this by
    keeping track of known superclasses, i.e. once a superclass has been
    processed, it is never again checked for nested classes, etc.
    
    Issue: SPR-8955
    cbeams committed Feb 14, 2012
  5. Polish static imports

    cbeams committed Feb 15, 2012
  6. Minor fix in ServletResponseMethodArgumentResolver

    Issues: SPR-8983
    rstoyanchev committed Feb 15, 2012