Branch in question is 'env' branch from git://git.springsource.org/sandbox/cbeams.git; merged into
git-svn repository with:

    git merge -s recursive -Xtheirs --no-commit env

No merge conflicts, but did need to

    git rm spring-build

prior to committing.

With this change, Spring 3.1.0 development is now happening on SVN
trunk. Further commits to the 3.0.x line will happen in an as-yet
uncreated SVN branch.  3.1.0 snapshots will be available
per the usual nightly CI build from trunk.

Fixed configuration of AnnotationAsyncExecutionAspect (was incorrectly under the same name as that for transaction management aspect)

added mode="proxy"/"aspectj" and proxy-target-class options to task namespace; switched to concise names for async aspects

fixed JodaTimeContextHolder to use a non-inheritable ThreadLocal and expose a reset method (SPR-7441); use of remove() even when being called with a null argument

SpEL MapAccessor consistently rejects "target.key" style access to Maps if no such key is found (SPR-7614)

fixed ApplicationContext event processing for repeated invocations to non-singleton listener beans (SPR-7563)

Before:

    - new GenericXmlApplicationContext("com/acme/path/to/resource.xml");

    - GenericXmlApplicationContext ctx = new GenericXmlApplicationContext();
      ctx.load("com/acme/path/to/resource.xml");
      ctx.refresh();

After:

    - The above remain supported, as well as new class-relative variants

    - import com.acme.path.to.Foo;
      new GenericXmlApplicationContext(Foo.class, "resource.xml");

    - import com.acme.path.to.Foo;
      GenericXmlApplicationContext ctx = new GenericXmlApplicationContext();
      ctx.load(Foo.class, "resource.xml");
      ctx.refresh();

These changes are generally aligned with signatures long available in
ClassPathXmlApplicationContext. As GenericXmlApplicationContext is
intended to be a more flexible successor to CPXAC (and FSXAC), it's
important that all the same conveniences are available.

consistent use of JDK 1.5's ThreadLocal.remove() over ThreadLocal.set(null), preventing leaks (SPR-7441)

GenericApplicationContext and AbstractRefreshableApplicationContext
implementations now call DefaultListableBeanFactory.setSerializationId()
only upon successful refresh() instead of on instantiation of the
context, as was previously the case with GAC.

DLBF.setSerializationId() adds the beanFactory to the *static*
DLBF.serializableFactories map, and while calling close() on the
application context removes entries from that map, it does so only if
the context is currently active (i.e. refresh() has been called).

Also, cancelRefresh() has been overridden in GAC just as it has been
in ARAC to accomodate the possibility of a BeansException being thrown.
In this case, the beanFactory serializationId will be nulled out and
the beanFactory removed from the serializableFactories map.

The SerializableBeanFactoryMemoryLeakTests test case provides full
coverage of these scenarios.

TaskExecutorFactoryBean (as used by task:executor) exposes full ThreadPoolTaskExecutor type (SPR-7403)

Spring field error arguments include actually declared annotation attributes in alphabetical order (SPR-6730)

JSR-303 Pattern message resolvable through Spring MessageSource (despite special characters; SPR-7329)

JSP EvalTag resolves "@myBeanName" references in expressions against the WebApplicationContext (SPR-7312); for consistency, expressions in an ApplicationContext support the same syntax against the local BeanFactory

added "validationMessageSource" property to LocalValidatorFactoryBean, for Spring-based messages (SPR-7307)

revised DefaultLifecycleProcessor's handling of circular dependencies to avoid stack overflow (SPR-7266)

CronTrigger defensively protects itself against accidental re-fires if a task runs too early (SPR-7004)

ScheduledTaskRegistrar (as used for @Scheduled processing) properly shuts down its default executor (SPR-6901)

refined LifecycleProcessor exception handling, properly wrapping a start exception from a bean (SPR-7106)