Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Commits on Feb 16, 2012
  1. @spring-buildmaster
  2. @cbeams

    Warn re Environment construction and instance vars

    cbeams authored
     - Add warning regarding access to default instance variable values
       during AbstractEnvironment#customizePropertySources callback
     - Polish AbstractEnvironment Javadoc and formatting
    Issue: SPR-9013
  3. @cbeams

    Disallow empty @PropertySource(value = {})

    cbeams authored
    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.
  4. @cbeams

    Fix @PropertySource bug with multiple values

    cbeams authored
    Prior to this commit, specifying a named @PropertySource with multiple
    values would not work as expected. e.g.:
          name = "ps",
          value = { "", "" })
    In this scenario, the implementation would register with
    the name "ps", and subsequently register with the name
    "ps", overwriting the entry for
    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
    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
  5. @jhoeller
  6. @jhoeller

    added "receive-timeout" attribute to "jms:listener-container" element…

    jhoeller authored
    … in JMS namespace (SPR-9114)
Commits on Feb 15, 2012
  1. @cbeams

    Demonstrate use of @Configuration as meta-annotation

    cbeams authored
    Issue: SPR-9090
  2. @cbeams
  3. @cbeams

    Apply @Configuration BeanNameGenerator consistently

    cbeams authored
    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
    This change ensures consistent application of custom BeanNameGenerator
    strategies in the following ways:
     - Introduction of AnnotationConfigUtils#CONFIGURATION_BEAN_NAME_GENERATOR
       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
     - 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
    Issue: SPR-9124
  4. @cbeams

    Improve @Configuration bean name discovery

    cbeams authored
    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:
      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.
      public class AppConfig {
          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
  5. @cbeams

    Fix infinite recursion bug in nested @Configuration

    cbeams authored
    Prior to this commit, an infinite recursion would occur if a
    @Configuration class were nested within its superclass, e.g.
      abstract class Parent {
          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
  6. @cbeams

    Polish static imports

    cbeams authored
  7. @rstoyanchev

    Minor fix in ServletResponseMethodArgumentResolver

    rstoyanchev authored
    Issues: SPR-8983
Commits on Feb 14, 2012
  1. @jhoeller
  2. @jhoeller

    prepared for 3.1.1 release

    jhoeller authored
  3. @jhoeller
  4. @jhoeller
  5. @jhoeller
  6. @jhoeller
  7. @jhoeller

    Resource "contentLength()" implementations work with OSGi bundle reso…

    jhoeller authored
    …urces and JBoss VFS resources (SPR-9118)
  8. @jhoeller
  9. @jhoeller
Commits on Feb 13, 2012
  1. @cbeams

    Fix false negative test failure in ResourceTests

    cbeams authored
    Prior to changes in commit 57851de,
    AbstractResource#getFilename threw IllegalStateException unless
    overridden by a subclass. Following that change, this method now throws
    null instead, but ResourceTests#testAbstractResourceExceptions had not
    been updated to reflect, resulting in a false negative failure. This has
    now been fixed.
    Issue: SPR-9043
  2. @cbeams

    Compensate for Eclipse vs Sun compiler discrepancy

    cbeams authored
    Eclipse allows autoboxing on type inference; Sun javac does not. This
    means that variables assigned from calls to
    AnnotationAttributes#getNumber should consistently use object wrappers
    as opposed to number primitives. There was only one such instance
    anyway, and has now been updated accordingly.
  3. @cbeams

    Compensate for changes in JDK 7 Introspector

    cbeams authored
    Prior to JDK 7, java.beans.Introspector registered indexed write methods
    irrespective of return type, for example either of the following methods
    were legal
        void setFoo(int i, Foo foo)
        Object setFoo(int i, Foo foo)
    This was considered a bug and disallowed starting with JDK 7, such that
    only the former signature is a candidate.
    Supporting non-void returning setter methods is exactly what
    ExtendedBeanInfo was designed to do, and prior to this commit, the
    implementation of ExtendedBeanInfo assumed this (somewhat surprising)
    behavior from the underlying Introspector, and because it worked out of
    the box, took no extra steps to recognize and register these methods.
    For this reason, non-void returning indexed write methods were not
    registered under JDK 7+, causing test failures in ExtendedBeanInfoTests.
    Now the implementation is careful to detect these methods without any
    assumption about Introspector behavior, such that they are registered in
    exactly the same fashion across JDK versions.
    Issue: SPR-9014
  4. @cbeams

    Avoid 'type mismatch' errors in ExtendedBeanInfo

    cbeams authored
    Prior to this commit, ExtendedBeanInfo would add non-indexed write
    methods without consideration for the presence of indexed read/write
    methods, which is invalid per the JavaBeans spec and per the behavior
    of java.beans.Introspector.  That is, a method with the signature
        void setFoo(Foo foo)
    Should never be registered as a write method if the following method
    signature is also present in the class
        void setFoo(int i, Foo foo)
    In most cases, this oversight caused no problems, but in certain
    situations where a bean actually contains such a mismatch of methods,
    "type mismatch" errors were thrown when ExtendedBeanInfo attempted the
    illegal addition against the underlying property descriptor.
    The implementation is now more careful about checking the parameter type
    of write methods -- if the property descriptor in question is an
    IndexedPropertyDescriptor, i.e. has an indexed write method, then any
    non-indexed write method candidate must have a single *array* parameter,
    which conforms to the spec and to Introspector behavior.
    Issue: SPR-8937
  5. @cbeams

    Polish ExtendedBeanInfo and tests

    cbeams authored
     - Reduce log messages from warn to debug
     - Remove now-incorrect comment indicating underlying property
       descriptors are never modified (they actually are as of SPR-8806)
     - Consolidate SPR-8949 tests
     - Eliminate compiler warnings
    Issue: SPR-8949, SPR-8806
  6. @cbeams

    Infer AnnotationAttributes method return types

    cbeams authored
     - Drop 'expectedType' parameter from #getClass and #getEnum methods and
       rely on compiler inference based on type of assigned variable, e.g.
         public @interface Example {
             Color color();
             Class<? extends UserType> userType();
             int order() default 0;
         AnnotationAttributes example =
            AnnotationUtils.getAnnotationAttributes(Example.class, true, true);
         Color color = example.getEnum("color");
         Class<? extends UserType> userType = example.getClass("userType");
       or in cases where there is no variable assignment (and thus no
       inference possible), use explicit generic type, e.g.
     - Rename #get{Int=>Number} and update return type from int to
       <N extends Number>, allowing invocations such as:
         int order = example.getNumber("order");
    These changes reduce the overall number of methods exposed by
    AnnotationAttributes, while at the same time providing comprehensive
    access to all possible annotation attribute types -- that is, instead of
    requiring explicit #getInt, #getFloat, #getDouble methods, the
    single #getNumber method is capabable of handling them all, and without
    any casting required. And the obvious additional benefit is more concise
    invocation as no redundant 'expectedType' parameters are required.
  7. @rstoyanchev

    Minor fix in MVC reference doc chapter

    rstoyanchev authored
    Issues: SPR-9111
Commits on Feb 12, 2012
  1. @jhoeller

    Merge pull request #33 from trisberg/SQLException-translation-enhance…

    jhoeller authored
    SQL exception translation enhancements
  2. @jhoeller

    Merge pull request #25 from trisberg/fixes-for-SimpleJdbcInsert

    jhoeller authored
    Fixes for SimpleJdbcInsert [SPR-9006]
Commits on Feb 11, 2012
  1. @jhoeller

    Hibernate 4.1 etc

    jhoeller authored
  2. @jhoeller
  3. @jhoeller
  4. @jhoeller
Something went wrong with that request. Please try again.