Issue: SPR-14728

In order to simplify configuration for use cases involving @Bean where
only a bean name or aliases are supplied as an attribute, this commit
introduces a new 'value' attribute that is an @AliasFor 'name' in @Bean.

Issue: SPR-14728

Issue: SPR-14282

Issue: SPR-11680

Issue: SPR-10128

  find . -type f -name "*.java" -or -name "*.aj" | \
    xargs perl -p -i -e "s/[ \t]*$//g" {} \;

Issue: SPR-10127

Also, @Bean destroy method inference not applying for DisposableBean implementers anymore (avoiding double destruction).

Issue: SPR-10034

Updated the "@Bean Lite Mode" section in order to properly document 
scoping and lifecycle semantics.

Also fleshed out the discussion of the non-applicability of 'inter-bean 
references' in lite mode.

Issue: SPR-9425

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

Issue: SPR-9401

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

Overhauled the class-level JavaDoc in @Bean:

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

Issue: SPR-9401

This renaming more intuitively expresses the relationship between
subprojects and the JAR artifacts they produce.

Tracking history across these renames is possible, but it requires
use of the --follow flag to `git log`, for example

    $ git log spring-aop/src/main/java/org/springframework/aop/Advisor.java

will show history up until the renaming event, where

    $ git log --follow spring-aop/src/main/java/org/springframework/aop/Advisor.java

will show history for all changes to the file, before and after the
renaming.

See http://chrisbeams.com/git-diff-across-renamed-directories

Anywhere the value of a destroy method may be expressed, specifying
the value "(inferred)" now indicates that the container should attempt
to automatically discover a destroy method. This functionality is
currently limited to detecting public, no-arg methods named 'close';
this is particularly useful for commonly used types such as Hibernate
SessionFactory most JDBC DataSource implementations, JMS connection
factories, and so forth.

This special value is captured as the constant
AbstractBeanDefinition#INFER_METHOD, which in turn serves as the default
value of the @Bean#destroyMethod attribute.

For example in the following case

    @Bean
    public BasicDataSource dataSource() { ... }

the container will automatically detect BasicDataSource#close and invoke
it when the enclosing ApplicationContext is closed. This is exactly
equivalent to

    @Bean(destroyMethod="(inferred)")
    public BasicDataSource dataSource() { ... }

A user may override this inference-by-default convention simply by
specifying a different method

    @Bean(destroyMethod="myClose")
    public MyBasicDataSource dataSource() { ... }

or, in the case of a bean that has an otherwise inferrable 'close'
method, but the user wishes to disable handling it entirely, an empty
string may be specified

    @Bean(destroyMethod="")
    public MyBasicDataSource dataSource() { ... }

The special destroy method name "(inferred)" may also be specified in
an XML context, e.g.

    <bean destroy-method="(inferred)">
        or
    <beans default-destroy-method="(inferred)">

Note that "(inferred)" is the default value for @Bean#destroyMethod,
but NOT for the destroy-method and default-destroy-method attributes
in the spring-beans XML schema.

The principal reason for introducing this feature is to avoid forcing
@Configuration class users to type destroyMethod="close" every time a
closeable bean is configured. This kind of boilerplate is easily
forgotten, and this simple convention means the right thing is done
by default, while allowing the user full control over customization or
disablement in special cases.

Issue: SPR-8751

In anticipation of 'destroy method inference' feature, introduce
ConfigurationClassUtils#INFER_METHOD and update @Bean#destroyMethod to
reflect its use.

Issue: SPR-8751

Declaring @Bean methods as 'static' is now permitted, whereas previously
it raised an exception at @Configuration class validation time.

A static @Bean method can be called by the container without requiring
the instantiation of its declaring @Configuration class. This is
particularly useful when dealing with BeanFactoryPostProcessor beans,
as they can interfere with the standard post-processing lifecycle
necessary to handle @Autowired, @Inject, @Value, @PostConstruct and
other annotations.

static @Bean methods cannot recieve CGLIB enhancement for scoping and
AOP concerns. This is acceptable in BFPP cases as they rarely if ever
need it, and should not in typical cases ever be called by another
@Bean method.  Once invoked by the container, the resulting bean will
be cached as usual, but multiple invocations of the static @Bean method
will result in creation of multiple instances of the bean.

static @Bean methods may not, for obvious reasons, refer to normal
instance @Bean methods, but again this is not likely a concern for BFPP
types. In the rare case that they do need a bean reference, parameter
injection into the static @Bean method is technically an option, but
should be avoided as it will potentially cause premature instantiation
of more beans that the user may have intended.

Note particularly that a WARN-level log message is now issued for any
non-static @Bean method with a return type assignable to BFPP.  This
serves as a strong recommendation to users that they always mark BFPP
@Bean methods as static.

See @Bean Javadoc for complete details.

Issue: SPR-8257, SPR-8269

Decomposed Environment interface into PropertySources, PropertyResolver
objects

    Environment interface and implementations are still present, but
    simpler.

    PropertySources container aggregates PropertySource objects;
    PropertyResolver provides search, conversion, placeholder
    replacement. Single implementation for now is
    PropertySourcesPlaceholderResolver

Renamed EnvironmentAwarePropertyPlaceholderConfigurer to
PropertySourcesPlaceholderConfigurer

    <context:property-placeholder/> now registers PSPC by default, else
    PPC if systemPropertiesMode* settings are involved

Refined configuration and behavior of default profiles

    See Environment interface Javadoc for details

Added Portlet implementations of relevant interfaces:

    * DefaultPortletEnvironment
    * PortletConfigPropertySource, PortletContextPropertySource
    * Integrated each appropriately throughout Portlet app contexts

Added protected 'createEnvironment()' method to AbstractApplicationContext

    Subclasses can override at will to supply a custom Environment
    implementation.  In practice throughout the framework, this is how
    Web- and Portlet-related ApplicationContexts override use of the
    DefaultEnvironment and swap in DefaultWebEnvironment or
    DefaultPortletEnvironment as appropriate.

Introduced "stub-and-replace" behavior for Servlet- and Portlet-based
PropertySource implementations

    Allows for early registration and ordering of the stub, then
    replacement with actual backing object at refresh() time.

    Added AbstractApplicationContext.initPropertySources() method to
    support stub-and-replace behavior. Called from within existing
    prepareRefresh() method so as to avoid impact with
    ApplicationContext implementations that copy and modify AAC's
    refresh() method (e.g.: Spring DM).

    Added methods to WebApplicationContextUtils and
    PortletApplicationContextUtils to support stub-and-replace behavior

Added comprehensive Javadoc for all new or modified types and members

Added XSD documentation for all new or modified elements and attributes

    Including nested <beans>, <beans profile="..."/>, and changes for
    certain attributes type from xsd:IDREF to xsd:string

Improved fix for detecting non-file based Resources in
PropertiesLoaderSupport (SPR-7547, SPR-7552)

    Technically unrelated to environment work, but grouped in with
    this changeset for convenience.

Deprecated (removed) context:property-placeholder
'system-properties-mode' attribute from spring-context-3.1.xsd

    Functionality is preserved for those using schemas up to and including
    spring-context-3.0.  For 3.1, system-properties-mode is no longer
    supported as it conflicts with the idea of managing a set of property
    sources within the context's Environment object. See Javadoc in
    PropertyPlaceholderConfigurer, AbstractPropertyPlaceholderConfigurer
    and PropertySourcesPlaceholderConfigurer for details.

Introduced CollectionUtils.toArray(Enumeration<E>, A[])

Work items remaining for 3.1 M2:

    Consider repackaging PropertySource* types; eliminate internal use
    of SystemPropertyUtils and deprecate

    Further work on composition of Environment interface; consider
    repurposing existing PlaceholderResolver interface to obviate need
    for resolve[Required]Placeholder() methods currently in Environment.

    Ensure configurability of placeholder prefix, suffix, and value
    separator when working against an AbstractPropertyResolver

    Add JNDI-based Environment / PropertySource implementatinos

    Consider support for @Profile at the @Bean level

    Provide consistent logging for the entire property resolution
    lifecycle; consider issuing all such messages against a dedicated
    logger with a single category.

    Add reference documentation to cover the featureset.

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.

revised support for annotated factory methods (merged @FactoryMethod functionality into JavaConfig facility)

+ Provide @Primary annotation (SPR-5590)
+ Provide @Lazy annotation (SPR-5591)
+ Test @Bean initMethod/destroyMethod functionality (SPR-5592)
+ Test @Bean dependsOn functionality (SPR-5593)

+ added objectweb.asm back to .classpath to satisfy transitive need from groovy tests
+ package.html -> package-info.java

+ Added testing-related TODOs where appropriate

+ Eliminated UsageError/Validatable/MalformedConfigurationException in favor of existing Problem/ProblemReporter types
+ Pruned a number of attributes from the @Bean and @Configuration annotations

+ Removed .ext package
+ Further reduced visibility of types wherever possible
+ Eliminated package cycles

+ Renamed ConfigurationPostProcessor -> ConfigurationClassPostProcessor
+ JavaDoc and polish for AbstractConfigurationClassProcessor