Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Commits on Jul 7, 2012
  1. @spring-buildmaster @cbeams

    Release version 3.1.2.RELEASE

    spring-buildmaster authored cbeams committed
Commits on Jul 6, 2012
  1. @jhoeller

    final preparations for 3.1.2

    jhoeller authored
  2. @jhoeller

    added "jtaTransactionManager" property to Hibernate 4 LocalSessionFac…

    jhoeller authored
    Issue: SPR-9480
  3. @jhoeller

    Add defaultCharset field to StringHttpMessageConverter

    jhoeller authored
    Before this change the StringHttpMessageConverter used a fixed charset "ISO-8859-1" if the requested content type did not specify one. This change adds a defaultCharset field and a constructor to configure it in StringHttpMessageConverter.
    Issue: SPR-9487
  4. @cbeams

    Resolve nested placeholders via PropertyResolver

    cbeams authored
    Prior to this change, PropertySourcesPropertyResolver (and therefore
    all AbstractEnvironment) implementations failed to resolve nested
    placeholders as in the following example:
    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
  5. @cbeams

    Add hamcrest to spring-aspects Eclipse classpath

    cbeams authored
    Also remove spring project nature from spring-context to avoid error in
Commits on Jul 4, 2012
  1. @jhoeller

    Cannot amend properties in RequestMappingHandlerMapping (e.g. useSuff…

    jhoeller authored
    …ixPatternMatch) using a bean post processor as ApplicationContextAwareProcessor always fires first initialising RequestMappingHandlerMapping
    Issue: SPR-9371
  2. @jhoeller

    Cannot amend properties in RequestMappingHandlerMapping (e.g. useSuff…

    jhoeller authored
    …ixPatternMatch) using a bean post processor as ApplicationContextAwareProcessor always fires first initialising RequestMappingHandlerMapping
    Issue: SPR-9371
  3. @jhoeller
  4. @jhoeller

    Cannot amend properties in RequestMappingHandlerMapping (e.g. useSuff…

    jhoeller authored
    …ixPatternMatch) using a bean post processor as ApplicationContextAwareProcessor always fires first initialising RequestMappingHandlerMapping
    Issue: SPR-9371
  5. @jhoeller

    preparations for 3.1.2

    jhoeller authored
  6. @jhoeller

    Cannot amend properties in RequestMappingHandlerMapping (e.g. useSuff…

    jhoeller authored
    …ixPatternMatch) using a bean post processor as ApplicationContextAwareProcessor always fires first initialising RequestMappingHandlerMapping
    Issue: SPR-9371
  7. @jhoeller

    DispatcherPortlet does not forward event exceptions to the render pha…

    jhoeller authored
    …se by default
    Issue: SPR-9287
  8. @jhoeller
  9. @jhoeller
Commits on Jul 2, 2012
  1. @jhoeller
Commits on Jun 28, 2012
  1. @jhoeller

    Make 'Content-Disposition' header case insensitive

    jhoeller authored
    Issue: SPR-9149
  2. @jhoeller

    XStreamMarshaller should convert XStream StreamException to Spring ex…

    jhoeller authored
    …ception in case of unmarshalling an empty stream.
    Issue: SPR-9536
Commits on Jun 27, 2012
  1. @cbeams

    Reflect 3.2=>3.1.2 backports in @since tags etc

    cbeams authored
    Issue: SPR-9443, SPR-6847, SPR-9446, SPR-9444, SPR-9439, SPR-9302,
           SPR-9507, SPR-9238, SPR-9397, SPR-9406, SPR-9502
  2. @cbeams

    Cache by-type lookups in DefaultListableBeanFactory

    cbeams authored
    Prior to this change, by-type lookups using DLBF#getBeanNamesForType
    required traversal of all bean definitions within the bean factory
    in order to inspect their bean class for assignability to the target
    type. These operations are comparatively expensive and when there are a
    large number of beans registered within the container coupled with a
    large number of by-type lookups at runtime, the performance impact can
    be severe. The test introduced here demonstrates such a scenario clearly.
    This performance problem is likely to manifest in large Spring-based
    applications using non-singleton beans, particularly request-scoped
    beans that may be created and wired many thousands of times per second.
    This commit introduces a simple ConcurrentHashMap-based caching strategy
    for by-type lookups; container-wide assignability checks happen only
    once on the first by-type lookup and are afterwards cached by type
    with the values in the map being an array of all bean names assignable
    to that type. This means that at runtime when creating and autowiring
    non-singleton beans, the cost of by-type lookups is reduced to that of
    Issue: SPR-9448
    Backport-Issue: SPR-6870
    Backport-Commit: 4c7a1c0
  3. @cbeams


    cbeams authored
    Issue: SPR-9448
    Backport-Issue: SPR-6870
    Backport-Commit: db1cb13
  4. @sbrannen @cbeams

    Fix regression in ClassPathResource descriptions

    sbrannen authored cbeams committed
    ClassPathResource.getDescription() now returns consistent, meaningful
    results for all variants of ClassPathResource's constructors.
    Issue: SPR-9415
    Backport-Issue: SPR-9413
    Backport-Commit: b50f6e1
  5. @Dridi @cbeams

    Fix scoped-proxy memory leak w/ @Resource injection

    Dridi authored cbeams committed
    Prior to this change, request-scoped components having
    @Resource-injected dependencies caused a memory leak in
    Consider the following example:
        @Scope(value="request", proxyMode=ScopedProxyMode.TARGET_CLASS)
        public class MyComponent {
            private HttpServletRequest request;
            // ...
    The bean name for "MyComponent" will end up being
    'scopedTarget.myComponent', which will become a key in
    the #dependenciesForBeanMap structure.
    On the first request, the injected HttpServletRequest bean will be a
    proxy and will internally have a bean name of the form
    "$Proxy10@1a3a2a52". This name will be added to the Set value associated
    with the 'scopedTarget.myComponent' entry in #dependenciesForBeanMap.
    On the second request, the process will repeat, but the injected
    HttpServletRequest will be a different proxy instance, thus having a
    different identity hex string, e.g. "$Proxy10@5eba06ff". This name will
    also be added to the Set value associated with the
    'scopedTarget.myComponent' entry in #dependenciesForBeanMap, and this
    is the source of the leak: a new entry is added to the set on each
    request but should be added only once.
    This commit fixes the leak by introducing caching to
    CommonAnnotationBeanPostProcessor#ResourceElement similar to that already
    present in AutowiredAnnotationBeanPostProcessor#AutowiredFieldElement
    and #AutowiredMethodElement. Essentially, each ResourceElement instance
    now tracks whether it has been created, caches the ultimate value to be
    injected and returns it eagerly if necessary. Besides solving the memory
    leak, this has the side effect of avoiding unnecessary proxy creation.
    This fix also explains clearly why injection into request-scoped
    components using @Autowired never suffered this memory leak: because the
    correct caching was already in place. Because @Resource is considerably
    less-frequently used than @Autowired, and given that this particular
    injection arrangement is relatively infrequent, it becomes
    understandable how this bug has been present without being reported
    since the introduction of @Resource support in Spring 2.5: developers
    were unlikely to encounter it in the first place; and if they did, the
    leak was minor enough (adding strings to a Set), that it could
    potentially go unnoticed indefinitely depending on request volumes and
    available memory.
    Issue: SPR-9363
    Backport-Issue: SPR-9176
    Backport-Commit: f779c19
  6. @cbeams

    Introduce BeanFactoryAnnotationUtils

    cbeams authored
    Commit 3f387eb refactored and
    deprecated TransactionAspectUtils, moving its #qualifiedBeanOfType
    and related methods into BeanFactoryUtils. This created a package cycle
    between beans.factory and beans.factory.annotation due to use of the
    beans.factory.annotation.Qualifier annotation in these methods.
    This commit breaks the package cycle by introducing
    beans.factory.annotation.BeanFactoryAnnotationUtils and moving these
    @Qualifier-related methods to it. It is intentionally similar in name
    and style to the familiar BeanFactoryUtils class for purposes of
    There are no backward-compatibilty concerns associated with this change
    as the cycle was introduced, caught and now fixed before a release.
    Issue: SPR-9443
    Backport-Issue: SPR-6847
    Backport-Commit: a4b00c7
  7. @cbeams

    Test meta-@Async executor qualification

    cbeams authored
    Prove that Async#value is respected even when using @Async as a meta
    Issue: SPR-9443
    Backport-Issue: SPR-6847
    Backport-Commit: 37e024c
  8. @cbeams

    Support executor qualification with @Async#value

    cbeams authored
    Prior to this change, Spring's @Async annotation support was tied to a
    single AsyncTaskExecutor bean, meaning that all methods marked with
    @Async were forced to use the same executor. This is an undesirable
    limitation, given that certain methods may have different priorities,
    etc. This leads to the need to (optionally) qualify which executor
    should handle each method.
    This is similar to the way that Spring's @Transactional annotation was
    originally tied to a single PlatformTransactionManager, but in Spring
    3.0 was enhanced to allow for a qualifier via the #value attribute, e.g.
      public void m() { ... }
    where ptm1 is either the name of a PlatformTransactionManager bean or
    a qualifier value associated with a PlatformTransactionManager bean,
    e.g. via the <qualifier> element in XML or the @Qualifier annotation.
    This commit introduces the same approach to @Async and its relationship
    to underlying executor beans. As always, the following syntax remains
      public void m() { ... }
    indicating that calls to #m will be delegated to the default executor,
    i.e. the executor provided to
      <task:annotation-driven executor=.../>
    or the executor specified when authoring a @Configuration class that
    implements AsyncConfigurer and its #getAsyncExecutor method.
    However, it now also possible to qualify which executor should be used
    on a method-by-method basis, e.g.
      public void m() { ... }
    indicating that calls to #m will be delegated to the executor bean
    named or otherwise qualified as e1. Unlike the default executor
    which is specified up front at configuration time as described above,
    the e1 executor bean is looked up within the container on the first
    execution of #m and then cached in association with that method for the
    lifetime of the container.
    Class-level use of Async#value behaves as expected, indicating that all
    methods within the annotated class should be executed with the named
    executor. In the case of both method- and class-level annotations, any
    method-level #value overrides any class level #value.
    This commit introduces the following major changes:
     - Add @Async#value attribute for executor qualification
     - Introduce AsyncExecutionAspectSupport as a common base class for
       both MethodInterceptor- and AspectJ-based async aspects. This base
       class provides common structure for specifying the default executor
       (#setExecutor) as well as logic for determining (and caching) which
       executor should execute a given method (#determineAsyncExecutor) and
       an abstract method to allow subclasses to provide specific strategies
       for executor qualification (#getExecutorQualifier).
     - Introduce AnnotationAsyncExecutionInterceptor as a specialization of
       the existing AsyncExecutionInterceptor to allow for introspection of
       the @Async annotation and its #value attribute for a given method.
       Note that this new subclass was necessary for packaging reasons -
       the original AsyncExecutionInterceptor lives in
       org.springframework.aop and therefore does not have visibility to
       the @Async annotation in org.springframework.scheduling.annotation.
       This new subclass replaces usage of AsyncExecutionInterceptor
       throughout the framework, though the latter remains usable and
       undeprecated for compatibility with any existing third-party
     - Add documentation to spring-task-3.2.xsd and reference manual
       explaining @Async executor qualification
     - Add tests covering all new functionality
    Note that the public API of all affected components remains backward-
    Issue: SPR-9443
    Backport-Issue: SPR-6847
    Backport-Commit: ed0576c
  9. @cbeams

    Polish async method execution infrastructure

    cbeams authored
    In anticipation of substantive changes required to implement @Async
    executor qualification, the following updates have been made to the
    components and infrastructure supporting @Async functionality:
     - Fix trailing whitespace and indentation errors
     - Fix generics warnings
     - Add Javadoc where missing, update to use {@code} tags, etc.
     - Avoid NPE in AopUtils#canApply
     - Organize imports to follow conventions
     - Remove System.out.println statements from tests
     - Correct various punctuation and grammar problems
    Issue: SPR-9443
    Backport-Issue: SPR-6847
    Backport-Commit: 3fb1187
  10. @cbeams

    Refactor and deprecate TransactionAspectUtils

    cbeams authored
    TransactionAspectUtils contains a number of methods useful in
    retrieving a bean by type+qualifier. These methods are functionally
    general-purpose save for the hard coding of PlatformTransactionManager
    class literals throughout.
    This commit generifies these methods and moves them into
    BeanFactoryUtils primarily in anticipation of their use by async method
    execution interceptors and aspects when performing lookups for qualified
    executor beans e.g. via @Async(qualifier).
    The public API of TransactionAspectUtils remains backward compatible;
    all methods within have been deprecated, and all calls to those methods
    throughout the framework refactored to use the new BeanFactoryUtils
    variants instead.
    Issue: SPR-9443
    Backport-Issue: SPR-6847
    Backport-Commit: 096693c
  11. @olivergierke @cbeams

    Use transactional connection during db population

    olivergierke authored cbeams committed
    Previously, DatabasePopulatorUtils#execute looked up a Connection from
    the given DataSource directly which resulted in the executed statements
    not being executed against a transactional connection (if any) which in
    turn resulted in the statements executed by the populator potentially
    not being rolled back.
    Now DataSourceUtils#getConnection is used to transparently take part in
    any active transaction and #releaseConnection is used to ensure the
    connection is closed if appropriate.
    Issue: SPR-9465
    Backport-Issue: SPR-9457
    Backport-Commit: 49c9a2a
  12. @cbeams

    Fix package cycle in @EnableSpringConfigured

    cbeams authored
    @EnableSpringConfigured and its @Import'ed
    SpringConfiguredConfiguration @Configuration class inadvertently
    established a package cycle between beans.factory.aspectj and
    context.annotation due to SpringConfiguredConfiguration's
    dependency on annotations such as @Configuration, @Bean and @Role.
    This commit fixes this architecture bug by moving
    @EnableSpringConfigured and SpringConfiguredConfiguration from the
    beans.factory.aspectj package to the context.annotation package where
    they belong.
    This change is assumed to be very low impact as @EnableSpringConfigured
    was introduced in 3.1.0 and relocation is happening as quickly as
    possible in 3.1.2. @EnableSpringConfigured is assumed to be infrequently
    used at this point, and for those that are the migration path
    is straightforward. When upgrading from Spring 3.1.0 or 3.1.1, update
    import statements in any affected @Configuration classes to reflect the
    new packaging.
    Backporter's note: this change causes Bundlor warnings in
    org.springframework.aspect as its manifest now "imports and exports the
    package org.springframework.context.annotation". To 'solve' this
    problem, `fail.on.warnings=false` has been added to
    This means that future Bundlor-based warnings may go unnoticed.
    Issue: SPR-9442
    Backport-Issue: SPR-9441
    Backport-Commit: 5327a7a
  13. @cbeams

    Introduce ConfigurableWebEnvironment

    cbeams authored
    Changes introduced in Spring 3.1 for Environment support inadvertently
    established a cyclic dependency between the
    org.springframework.web.context and packages, specifically through
    web.context.ContextLoader's invocation of
    This commit introduces ConfigurableWebEnvironment to break this cyclic
    dependency. All web.context.ConfigurableWebApplicationContext types now
    return web.context.ConfigurableWebEnvironment from their #getEnvironment
    methods; now implements
    ConfigurableWebEnvironment and makes the call to
    within its implementation of #initPropertySources. This means that
    web.context.ContextLoader now invokes
    web.context.ConfigurableWebEnvironment#initPropertySources instead of
    and thus the cycle is broken.
    Issue: SPR-9440
    Backport-Issue: SPR-9439
    Backport-Commit: 2a2b6ee
  14. @cbeams

    Introduce ConfigurableEnvironment#merge

    cbeams authored
    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-9446
    Backport-Issue: SPR-9444, SPR-9439
    Backport-Commit: 9fcfd7e
  15. @cbeams

    Reduce log level for message re: missing annotation

    cbeams authored
    Previously (since Spring 3.1.1) RecursiveAnnotationAttributesVisitor
    logs at level WARN when ASM parsing encounters an annotation or an (enum
    used within an annotation) that cannot be classloaded. This is not
    necessarily indicative of an error, e.g. JSR-305 annotations such as
    @Nonnull may be used only for static analysis purposes, but because
    these annotations have runtime retention, they remain present in the
    bytecode. Per section of the JLS, "An annotation that is present
    in the binary may or may not be available at run-time via the reflective
    libraries of the Java platform."
    This commit lowers the log level of these messages from warn to debug,
    but leaves at warn level other messages dealing with the ability
    reflectively read enum values from within annotations.
    Issue: SPR-9447
    Backport-Issue: SPR-9233
    Backport-Commit: f55a4a1
  16. @rstoyanchev

    Fix issue with encoded params in UriComponentsBuilder

    rstoyanchev authored
    The fromUri method of UriComponentsBuilder used uri.getXxx() methods,
    which decode the URI parts causing URI parsing issues. The same method
    now uses uri.getRawXxx().
    Issue: SPR-9317
    Backport-Issue: SPR-9549
    Backport-Commit: a33fe6f
Commits on Jun 26, 2012
  1. @rstoyanchev

    Update changelog

    rstoyanchev authored
Something went wrong with that request. Please try again.