Pattern suffix issue in AnnotationMethodHandlerAdapter

SPR-9333
Improve documentation for configuration class 'lite' mode

Overhauled the class-level JavaDoc in @Bean:

 - added h3 headers for greater clarity and readability
 - mentioned 'prototype' semantics for lite mode

Issue: SPR-9401
Fix minor grammatical errors in AbstractBeanDefinition
Fix annotation search ending too early

In AnnotationUtils#findAnnotation(Method, Class), the search for a
method annotation fails if:

 - the original method does not have the annotation

 - an abstract superclass does not have an equivalent method declared

 - an interface implemented by the superclass has the method and
   the annotation -> this should be found, but is not!

This happens because the try-catch block in #findAnnotation is too wide:
cl.getDeclaredMethod() can throw NoSuchMethodException and skip the
'#searchOnInterfaces' call prematurely.

The try-catch block was made narrower to allow #searchOnInterfaces to
be called even if the abstract class does not have the method declared
at all.

Issue: SPR-9342
Merge pull request #81 from JanecekPetr/SPR-9342

* SPR-9342:
  Fix annotation search ending too early
Improve documentation of @Bean 'lite' mode

Updated the class-level JavaDoc for @Bean to better explain the
semantics of 'lite' mode.

Renamed "Configuration Class Lite Mode" to "@Bean Lite Mode".

Added discussion of @DependsOn to the class-level JavaDoc.

Issue: SPR-9401
Improve documentation of @Bean 'lite' mode

Removed misleading mention of "configuration classes" in the
"@Bean Lite Mode" section.

Issue: SPR-9401
Fix locale parsing error with en_en, tr_tr, etc

Previously, StringUtils#parseLocaleString would parse locale strings
having the same lowercase token for both language and country
incorrectly, e.g. 'tr_tr' would parse to 'tr_TR_tr' as opposed to the
expected 'tr_TR'.

This commit fixes this behavior by using using String#lastIndexOf
instead of String#indexOf when determining the location of the country
code token.

Issue: SPR-9420
Fix property replacement bug in Log4jWebConfigurer

Previously, if the resolution of a ${...} placeholder resulted in a
valid URL for the location of a log4j properties/XML file, the URL
would ultimately be malformed by an unnecessary call to to
WebUtils#getRealPath.

The implementation of Log4jWebConfigurer#initLogging now eagerly
attempts SystemPropertyUtils#resolvePlaceholders before checking to see
if the location is a valid URL, and bypassing the call to
WebUtils#getRealPath if so.

Issue: SPR-9417
Fix SpEL JavaBean compliance

Before this fix ReflectivePropertyAccessor was not able to find write
method for valid property name that has first character in lower case
and second character in upper case. Write method lookup would always
convert first character of property name to upper case which is not
compliant with JavaBean specification. As consequence this caused an
unwanted behavior in SpEL when obtaining values of expressions that
reference such JavaBean properties.

As of this change, write method lookup skips conversion of property
name first character to upper case when property name is longer than
one character and second character is in upper case. This also fixes
mentioned bug in SpEL value resolution.

Issue: SPR-9123
Merge pull request #49 from sslavic/SPR-9123

* SPR-9123:
  Fix SpEL JavaBean compliance
Fix JibxMarshallerTests failing on Windows

Before this change JibxMarshallerTests would fail on Windows with an
error message explaining that JiBX compiler generated classes are not
found on the classpath for binding with name 'binding'. Tests would
execute well on Linux and OS X.

Actual root cause of this bug is found to be in JiBX 1.1.5 release that
is used to build Spring. The binding name can be explicitly specified in
JiBX binding file. If omitted, when generating classes the JiBX compiler
as fall-back mechanism tries to derive the binding name from the binding
file name. That logic had a bug which gets manifested when configured
binding file path has mixed Windows and *nix style file separators, as
in case of JibxMarshallerTests being executed on a Windows platform.

This commit resolves this issue by upgrading Spring's build from JiBX
1.1.5 to 1.2.3, as the bug mentioned was fixed in JiBX 1.2. See JIBX-441
for more details.

Issue: SPR-8360
Merge pull request #59 from sslavic/SPR-8360

* SPR-8360:
  Fix JibxMarshallerTests failing on Windows
Allow null params as advertised in Constants#toCode*

Even though the Javadoc for Constants#toCode and #toCodeForSuffix
specifies that a null value for the 'namePrefix' and 'nameSuffix'
parameters are respectively allowed, before this change passing a null
to either would result in a NullPointerException.

This change fixes constant name lookup for null values of these params
as if an empty string had been passed instead. This way of handling a
null value is consistent with the rest of Constants class API.

Issue: SPR-8278
Fix compiler warnings in Constants/ConstantsTests
Merge pull request #57 from sslavic/SPR-8278

* SPR-8278:
  Fix compiler warnings in Constants/ConstantsTests
  Allow null params as advertised in Constants#toCode*
Support [] array ref syntax in SpEL T() construct

Prior to this change, SpEL would not allow the use of '[]' in
expressions like the following:

    T(foo.Bar[])

This commit updates TypeReference and InternalSpelExpressionParser to
support this syntax, avoiding the need for workarounds like:

    new foo.bar[0].class

Issue: SPR-9203
Eliminate trailing whitespace in SpEL classes
Merge pull request #53 from aclement/SPR-9203

* SPR-9203:
  Eliminate trailing whitespace in SpEL classes
  Support [] array ref syntax in SpEL T() construct
Fix compiler warnings

This patch fixes several compiler warnings that do not point to code
problems. Two kinds of warnings are fixed. First in a lot of cases
@SuppressWarnings("unchecked") is used although there are no unchecked
casts happening. This seems to be a leftover from when the code base
was on Java 1.4, now that the code base was moved to Java 1.5 these are
no longer necessary. Secondly there some places where the raw types of
List and Class are used where there wildcard types (List<?> and
Class<?>) would work just as well without causing any raw type warnings.

These changes are beneficial particularly when working in Eclipse or
other IDEs because it reduces 'noise', helping to isolate actual
potential problems in the code.

The following changes have been made:

 - remove @SuppressWarnings where no longer needed

 - use wildcard types instead of raw types where possible