added "receive-timeout" attribute to "jms:listener-container" element in JMS namespace (SPR-9114)
final preparations for 3.1.1 release
Fix @PropertySource bug with multiple values

Prior to this commit, specifying a named @PropertySource with multiple
values would not work as expected. e.g.:

  @PropertySource(
      name = "ps",
      value = { "classpath:a.properties", "classpath:b.properties" })

In this scenario, the implementation would register a.properties with
the name "ps", and subsequently register b.properties with the name
"ps", overwriting the entry for a.properties.

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
specified.

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
Disallow empty @PropertySource(value = {})

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.
Warn re Environment construction and instance vars

 - Add warning regarding access to default instance variable values
   during AbstractEnvironment#customizePropertySources callback

 - Polish AbstractEnvironment Javadoc and formatting

Issue: SPR-9013
Sync with 3.1.x

* 3.1.x:
  Warn re Environment construction and instance vars
  Disallow empty @PropertySource(value = {})
  Fix @PropertySource bug with multiple values
  final preparations for 3.1.1 release
  added "receive-timeout" attribute to "jms:listener-container" element
Fix regression in @PropertySource placeholder resolution

Changes in commit 41ade68b50b39485b3cf02b9c6fb8eb74962146b introduced
a regression causing all but the first location in the
@PropertySource#value array to be ignored during ${...} placeholder
resolution. This change ensures that all locations are processed and
replaced as expected.

Issue: SPR-9133, SPR-9127
Map ORA-30006 to CannotAcquireLockException as well

ORA-00054 is already mapped to CannotAcquireLockException and is
described as

  "resource busy and acquire with NOWAIT specified"

As pointed out in the associated JIRA issue, ORA-30006 is quite similar
being described as

  "resource busy; acquire with WAIT timeout expired"

This commit maps ORA-30006 to CannotAcquireLockException as well.

Issue: SPR-9141
Predict specific object type in EhCacheFactoryBean

Prior to this change, before a bean is created by EhCacheFactoryBean,
its #getObjectType would return only an Ehcache interface. This caused
unwanted wiring issues as described in the related JIRA issue.

This fix makes use of EhCacheFactoryBean's configuration to determine
the specific Ehcache object type even before it's created, such that
the container is provided with as much information as possible when
resolving dependencies. Nevertheless, users are advised to code to
the Ehcache interface.

Issue: SPR-7843
Merge pull request #41 from sslavic/SPR-7843

* SPR-7843:
  Predict specific object type in EhCacheFactoryBean
Upgrade to docbook-reference-plugin 0.1.3
Upgrade to Gradle 1.0-milestone-8a

 - Rename customized .wrapper to default gradle/wrapper directory for
   out of the box compatibility with STS Gradle tooling

 - Add .settings/gradle directory to capture defaults when using STS
   Gradle tooling to import projects
Avoid infinite loop in AbstractResource#contentLength

Due to changes made in commit 2fa87a71 for SPR-9118,
AbstractResource#contentLength would fall into an infinite loop unless
the method were overridden by a subclass (which it is in the majority of
use cases).

This commit:

 - fixes the infinite recursion by refactoring to a while loop

 - asserts that the value returned from #getInputStream is not null in
   order to avoid NullPointerException

 - tests both of the above

 - adds Javadoc to the Resource interface to clearly document that the
   contract for any implementation is that #getInputStream must not
   return null

Issue: SPR-9161
Support byte[] in JaxbMarshaller under JDK 7

JDK7 changed its reflections API in order to resolve
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5041784

In short, JDK 5 and 6 (wrongly) return GenericArrayTypes in certain
reflection scenarios, whereas JDK 7 changed this to return a normal
array type. For Jaxb2Marshaller, this meant that marshaling byte arrays
was not supported under JDK 7.

This change fixes that, so that Jaxb2Marhsaller supports marshalling
byte arrays again (under JDK 5, 6 or 7).
Support scanned classes in Jaxb2Marshaller

Jaxb2Marshaller#supports now supports classes found via package
scanning.

Issue: SPR-9152
Return null correctly from MutablePropertySources#get

Prior to this commit, MutablePropertySources#get(String) would throw
IndexArrayOutOfBoundsException if the named property source does not
actually exist. This is a violation of the PropertySource#get contract
as described in its Javadoc.

The implementation now correctly checks for the existence of the named
property source, returning null if non-existent and otherwise returning
the associated PropertySource.

Other changes

 - Rename PropertySourcesTests => MutablePropertySourcesTests
 - Polish MutablePropertySourcesTests for style, formatting
 - Refactor MutablePropertySources for consistency

Issue: SPR-9179
Fix typo in ApplicationContext reference doc

 - Add missing '=' sign in sample code for section 4.2.3

Issue: SPR-8856
Fix typo in spring:eval taglib reference doc

 - Replace 'javascriptEncoding' with 'javaScriptEscape'

Issue: SPR-9188
Merge pull request #46 from pkan/master

* pkan/master:
  Fix typo in spring:eval taglib reference doc
  Fix typo in ApplicationContext reference doc
Remove note on singleton-scoped proxy raising BCE

Before this change bean scopes chapter in Spring reference documentation
had a note which mentioned that creating a scoped proxy for singleton-
or prototype-scoped beans will throw BeanCreationException.

This is no longer the case and this change removes the mentioned note.

Issue: SPR-7940