Commits on May 4, 2012
  1. Exception for OSIV deferred close with async requests

    rstoyanchev committed May 4, 2012
    OSIV deferred close mode is not supported with async requests and is
    unlikely to be what's the desired. This change adds an exception with
    a message stating this.
    Issue: SPR-8517
  2. Merge pull request #73 from rstoyanchev/mvc-async

    rstoyanchev committed May 4, 2012
    HanderInterceptor and OSIV async request changes
  3. HanderInterceptor and OSIV async request changes

    rstoyanchev committed Apr 27, 2012
    This change updates Open-Session-in-View filters and interceptors for
    use in async requests mainly ensuring the open Hibernate session is
    unbound from the main request processing thread and bound to the to
    async thread.
    Issue: SPR-8517
Commits on May 1, 2012
  1. Add empty location check to ResourceHttpRequestHandler

    rstoyanchev committed May 1, 2012
    ResourceHttpRequestHandler now implements InitializingBean and
    checks for empty locations.
    Issue: SPR-9186
  2. Javadoc update

    rstoyanchev committed May 1, 2012
    Issue: SPR-9265
  3. Fix issue with encoded params in UriComponentsBuilder

    rstoyanchev committed May 1, 2012
    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
  4. Merge pull request #66 from dridi/SPR-9176

    cbeams committed May 1, 2012
    * SPR-9176:
      Fix scoped-proxy memory leak w/ @Resource injection
  5. Fix scoped-proxy memory leak w/ @Resource injection

    Dridi authored and cbeams committed Apr 16, 2012
    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-9176
Commits on Apr 30, 2012
  1. Merge pull request #7 from bedla/SPR-8308

    cbeams committed Apr 30, 2012
    * SPR-8308:
      Convert SpEL plus operands using reg'd converters
  2. Convert SpEL plus operands using reg'd converters

    bedla authored and cbeams committed Dec 18, 2011
    Prior to this commit, SpEL's OpPlus ('+' operator) would convert its
    left and right operands to String directly via #toString calls.
    This change ensures that operand values are delegated to any registered
    converters, allowing for customization of the stringified output.
    Note that the OpPlus constructor now throws IllegalArgumentException if
    zero operands are supplied.
    Issue: SPR-8308
  3. Merge pull request #36 from sslavic/SPR-9113

    cbeams committed Apr 30, 2012
    * SPR-9113:
      Fix javadoc warnings
  4. Fix javadoc warnings

    sslavic authored and cbeams committed Feb 12, 2012
    Before this change there were numerous javadoc warnings being reported
    while building Spring framework API.
    This commit resolves most of the javadoc warnings, reducing the total
    number from 265 to 103.
    Issue: SPR-9113
  5. Merge pull request #35 from sslavic/SPR-9097

    cbeams committed Apr 30, 2012
    * SPR-9097:
      Fix encoding issues in javadoc
  6. Fix encoding issues in javadoc

    sslavic authored and cbeams committed Feb 12, 2012
    Before this change javadoc in two classes had non-UTF-8 encoded
    characters. This caused building Spring API to fail in Java 1.7.
    Commit fixes this by replacing wrongly encoded characters with their
    UTF-8 equivalents.
    Issue: SPR-9097
Commits on Apr 26, 2012
  1. Add ability to handle a timeout to DeferredResult

    rstoyanchev committed Apr 26, 2012
    When a controller returns a DeferredResult, the underlying async
    request will eventually time out. Until now the default behavior was
    to send a 503 (SERVICE_UNAVAILABLE). However, this is not desirable
    in all cases. For example if waiting on an event, a timeout simply
    means there is no new information to send.
    To handle those cases a DeferredResult now accespts a timeout result
    Object in its constructor. If the timeout occurs before the
    DeferredResult is set, the timeout result provided to the constructor
    is used instead.
    Issue: SPR-8617
Commits on Apr 23, 2012
  1. Polish Servlet async request processing

    rstoyanchev committed Apr 23, 2012
    * Clarify semantics and behavior of AsyncWebRequest methods in most cases
    making a best effort and not raising an exception if async processing
    has completed for example due to a timeout. The startAsync() method is
    still protected with various checks and will raise ISE under a number
    of conditions.
    * Return 503 (service unavailable) when requests time out.
    * Logging improvements.
    Issue: SPR-8517
Commits on Apr 20, 2012
  1. Upgrade to docbook-reference-plugin 0.1.5

    cbeams committed Apr 20, 2012
     - Fixes deprecation warnings associated with recent upgrade to Gradle
Commits on Apr 18, 2012
  1. Fix broken test

    rstoyanchev committed Apr 18, 2012
    Issue: SPR-8517
  2. Initial cut of Servlet 3.0 based async support

    rstoyanchev committed Apr 13, 2012
    From a programming model perspective, @RequestMapping methods now
    support two new return value types:
    * java.util.concurrent.Callable - used by Spring MVC to obtain the
    return value asynchronously in a separate thread managed transparently
    by Spring MVC on behalf of the application.
    * org.springframework.web.context.request.async.DeferredResult - used
    by the application to produce the return value asynchronously in a
    separate thread of its own choosing.
    The high-level idea is that whatever value a controller normally
    returns, it can now provide it asynchronously, through a Callable or
    through a DeferredResult, with all remaining processing --
    @ResponseBody, view resolution, etc, working just the same but
    completed outside the main request thread.
    From an SPI perspective, there are several new types:
    * AsyncExecutionChain - the central class for managing async request
    processing through a sequence of Callable instances each representing
    work required to complete request processing asynchronously.
    * AsyncWebRequest - provides methods for starting, completing, and
    configuring async request processing.
    * StandardServletAsyncWebRequest - Servlet 3 based implementation.
    * AsyncExecutionChainRunnable - the Runnable used for async request
    All spring-web and spring-webmvc Filter implementations have been
    updated to participate in async request execution.
    The open-session-in-view Filter and interceptors implementations in
    spring-orm will be updated in a separate pull request.
    Issue: SPR-8517
Commits on Apr 17, 2012
  1. Upgrade slf4j-api and -log4j12 dependencies to 1.6.1

    cbeams committed Apr 17, 2012
    Previously depending on 1.5.10 in certain locations, which caused
    NoClassDefFoundErrors in EhCacheCacheTests and other tests due to
    mismatches between slf4j -api and -log4j12 versions.
    With the exception of one transitive dependency via Hibernate 3.3.1.GA,
    all slf4j dependencies are now pegged at 1.6.1 (and all tests pass).
  2. Merge pull request #61 from rstoyanchev/slf4j-dependency

    cbeams committed Apr 17, 2012
    * rstoyanchev/slf4j-dependency:
      Fix transitive dependency issue with slf4j-api
Commits on Apr 16, 2012
  1. Fix transitive dependency issue with slf4j-api

    rstoyanchev committed Mar 30, 2012
    Before this change, IDE settings generated via
    created a classpath dependency on slf4j-api version 1.6.1 and
    slf4j-log4j12 version 1.5.10. As a result running tests inside the IDE
    resulted in a NoSuchMethodException.
    build.gradle sets the variable slf4jLog4jVersion to '1.5.10'. However,
    the hibernate-validator dependency in spring-context pulls in
    slf4j-api version 1.6.1. The change ensures the version specified in
    the build script variable is used consistently. Whether it should be
    1.5.10 or 1.6.1 is a separate concern.
Commits on Apr 14, 2012
  1. Upgrade AspectJ from 1.6.8 to 1.6.12

    cbeams committed Apr 14, 2012
     - Spring remains compatible against AJ version 1.6.8, but is now
       compiling and testing against 1.6.12
     - Encountered what appears to be an AJ bug introduced in 1.6.10: an
       assertion in org.aspectj.weaver.UnresolvedType causes a false
       negative failure when encountering
       arrays, e.g. "[". This problem
       has been reported to the AJ team and in the meantime, the recommended
       workaround is to disable assertions either completely, or at least
       selectively with
    Issue: SPR-7989, SPR-9272
  2. Upgrade to Gradle 1.0-rc1

    cbeams committed Apr 14, 2012
     - Fix deprecation warnings about dynamic properties; favor use of
       "extra properties extensions" per [1]
     - Certain such deprecations are still issued due to violations within
       the docbook-reference plugin. These will be fixed in an upcoming
       revision of the plugin, at which point spring-framework will upgrade
       to depend on it and these warnings will be eliminated
    Issue: SPR-9327
Commits on Apr 13, 2012
  1. Fix typo in reference documentation

    cbeams committed Apr 13, 2012
    Issue: SPR-9321
Commits on Apr 6, 2012
  1. Use the type of the actual return value in @MVC

    rstoyanchev committed Apr 6, 2012
    The new @MVC support classes select a HandlerMethodArgumentResolver
    and a HandlerMethodReturnValueHandler statically, i.e. based on
    the signature of the method, which means that a controller method
    can't declare a more general return type like Object but actually
    return a more specific one, e.g.  String vs RedirectView, and
    expect the right handler to be used.
    The fix ensures that a HandlerMethodReturnValueHandler is selected
    based on the actual return value type, which is something that was
    supported with the old @MVC support classes. One consequence
    of the change is the selected HandlerMethodReturnValueHandler can
    no longer be cached but that matches the behavior of the old
    @MVC support classes.
    Issues: SPR-9218
  2. Minor improvement in ExceptionHandlerExceptionResolver

    rstoyanchev committed Apr 6, 2012
    Moved a null check inside a protected method to give protected method
    a chance to override what happens in that case.
    Issues: SPR-9193
Commits on Apr 2, 2012
  1. Make 'Content-Disposition' header case insensitive

    rstoyanchev committed Apr 2, 2012
    Previously 'Content-Disposition' was passed to Part.getHeader(String).
    However the Javadoc for that method specifies the header should be
    case insensitive. Note that the JavaDoc in tomcat-servlet-api doesn't
    mention this. It can only be found in the official api JavaDoc:
    Issue: SPR-9149
  2. Fix issue with parsing media types

    rstoyanchev committed Apr 2, 2012
    Invalid Content-Type or Accept header values previously resulted in the
    IllegalArgumentException getting propagated. After this change such
    errors are detected and generally treated as a "no match", which
    may for example result in a 406 in the case of the Accept header.
    Issue: SPR-9148
  3. Fix race condition in AnntationMethodHER

    rstoyanchev committed Apr 2, 2012
    Issues: SPR-9138
  4. Fix bug with custom RequestCondition

    rstoyanchev committed Apr 2, 2012
    A custom RequestCondition which can be provided by overriding methods
    in RequestMappingHandlerMapping worked only for conditions that match
    and did not return null (as it should have) for conditions that don't
    Issues: SPR-9134
  5. Improvement in AntPathMatcher.combine method

    rstoyanchev committed Apr 2, 2012
    Issues: SPR-7970
Commits on Mar 26, 2012
  1. Fix typo in util:constant error reporting

    cbeams committed Mar 26, 2012
    Issue: SPR-9260
  2. Introduce 3.2 versions of Spring XML namespaces

    cbeams committed Mar 15, 2012
    Copy spring-*-3.1.xsd => spring-*-3.2.xsd; this commit introduces no
    substantive changes, but rather prepares for them by creating a clean
    baseline. All internal references to 3.1 schemas (e.g. spring-tool) have
    also been updated.