Commits on Dec 21, 2011
  1. further post-GA fixes

    jhoeller committed Dec 21, 2011
  2. prepared for 3.1.1

    jhoeller committed Dec 21, 2011
Commits on Dec 20, 2011
  1. Minor copy edits to README

    cbeams committed Dec 20, 2011
  2. Merge pull request #8 from cbeams/master

    cbeams committed Dec 20, 2011
    Add readme
  3. Add readme

    cbeams committed Dec 20, 2011
Commits on Dec 15, 2011
  1. IntelliJ IDEA 11 project setup

    jhoeller committed with cbeams Dec 15, 2011
  2. Add spring-build 2.5.2

    cbeams committed Dec 15, 2011
    spring-build was previously included via an svn:external. Adding
    directly to the source tree under Git to avoid the need for a git
    In order to build from any earlier commit, it is recommended to
    export spring-build or symlink an existing copy into the root
    of the spring-framework project and then build normally.
        $ svn export spring-build
Commits on Dec 12, 2011
  1. Polish Javadoc

    cbeams committed Dec 12, 2011
  2. overhaul of support package arrangements for handler method processin…

    jhoeller committed Dec 12, 2011
    …g; added missing package-info files
  3. Re-introduce system-properties-mode to spring-context 3.1 XSD

    cbeams committed Dec 12, 2011
    See JIRA issue for complete details.
    Issue: SPR-8901
  4. SmartLifecycle beans in Lifecycle dependency graphs are only being st…

    jhoeller committed Dec 12, 2011
    …arted when isAutoStartup=true (SPR-8912)
  5. do not reset Session itself on "clear()" in order to properly interac…

    jhoeller committed Dec 12, 2011
    …t with Open Session in View (SPR-8909)
  6. "dispatchOptionsRequest" only sets the default 'Allow' header if actu…

    jhoeller committed Dec 12, 2011
    …ally needed (SPR-7837); "dispatchTraceRequest" only generates default response body if actually needed
  7. polishing

    jhoeller committed Dec 12, 2011
  8. Preserve programmatically set context config locations

    cbeams committed Dec 12, 2011
    Prior to this fix, ContextLoader(Listener)'s would overwrite any
    value set directly against a WebApplicationContext's #setConfigLocation
    method. This is a likely scenario when using Spring 3.1's new
    WebApplicationInitializer support.
    Now a check is performed to ensure that the ContextLoader init-param
    value is non-null before doing the overwriting.
    Added tests to ensure that all expected precedence, overwriting and
    defaulting of context config locations works as expected.
    Issue: SPR-8510
Commits on Dec 11, 2011
  1. polishing

    jhoeller committed Dec 11, 2011
  2. reworked JsonMessageConverter contribution into MappingJacksonMessage…

    jhoeller committed Dec 11, 2011
    …Converter, aligned with MappingJacksonHttpMessageConverter and MappingJacksonJsonView
  3. polishing

    jhoeller committed Dec 11, 2011
  4. polishing

    jhoeller committed Dec 11, 2011
  5. @Transactional qualifiers match against transaction manager definitio…

    jhoeller committed Dec 11, 2011
    …ns in parent contexts as well (SPR-7679)
  6. Support use of @Scheduled against JDK proxies

    cbeams committed Dec 11, 2011
    Prior to this change, ScheduledAnnotationBeanPostProcessor found any
    @Scheduled methods against the ultimate targetClass for a given bean
    and then attempted to invoke that method against the bean instance. In
    cases where the bean instance was in fact a JDK proxy, this attempt
    would fail because the proxy is not an instance of the target class.
    Now SABPP still attempts to find @Scheduled methods against the target
    class, but subsequently checks to see if the bean is a JDK proxy, and if
    so attempts to find the corresponding method on the proxy itself. If it
    cannot be found (e.g. the @Scheduled method was declared only at the
    concrete class level), an appropriate exception is thrown, explaining to
    the users their options: (a) use proxyTargetClass=true and go with
    subclass proxies which won't have this problem, or (b) pull the
    @Scheduled method up into an interface.
    Issue: SPR-8651
Commits on Dec 10, 2011
  1. Allow parameters in FactoryBean-returning @Bean methods

    cbeams committed Dec 10, 2011
    Prior to this change, an assumption was made in
    AbstractAutowireCapableBeanFactory that any factory-method would have
    zero parameters.  This may not be the case in @Bean methods.
    We now look for the factory-method by name in a more flexible fashion
    that accomodates the possibility of method parameters.
    There remains at least one edge cases here where things could still fail,
    for example a @Configuration class could have two FactoryBean-returning
    methods of the same name, but each with different generic FactoryBean
    types and different parameter lists. In this case, the implementation
    may infer and return the wrong object type, as it currently returns
    the first match for the given factory-method name.  The complexity cost
    of ensuring that this never happens is not likely worth the trouble
    given the very low likelihood of such an arrangement.
    Issue: SPR-8762