In particular, avoid accidental usage of ASM for core JDK types - which will fail in case of a new bytecode version in the JDK, even if the application itself has been compiled with an earlier bytecode target.

Issue: SPR-10292

ConfigurationClassPostProcessor consistently uses ClassLoader, not loading core JDK annotations via ASM

Issue: SPR-10249

This reverts commit 45fa5082, reversing
changes made to a312d900.

Issue: SPR-10130

Issue: SPR-10058

Implementations of Spring's ImportBeanDefinitionRegistrar interface may
now implement any of the following *Aware interfaces and have their
respective methods called prior to #registerBeanDefinitions:

 - BeanFactoryAware
 - BeanClassLoaderAware
 - ResourceLoaderAware

Issue: SPR-9568

Issue: SPR-9925

Issue: SPR-9925

Refactor ConfigurationClassParser to recursively find values from
all @Import annotations, combining them into a single unique set.

This change prevents ImportBeanDefinitionRegistrars from being
invoked twice.

Issue: SPR-9925

Prior to this change, @ComponentScan required the declaration of
exactly one of the #value, #basePackage or #basePackageClasses
attributes in order to determine which package(s) to scan.

This commit introduces support for base package inference, relaxing the
above requirement and falling back to scanning the package in which the
@ComponentScan-annotated class is declared.

Issue: SPR-9586

Issue: SPR-9243

Changes in commit 41ade68b 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

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

Prior to this change, a @Configuration classes that @ComponentScan
themselves would result in a ConflictingBeanDefinitionException.

For example:

    package com.foo.config;

    @Configuration
    @ComponentScan("com.foo");
    public class AppConfig {
        // ...
    }

This resulted in a ConflictingBeanDefinitionException that users have
typically worked around in the following fashion:

    package com.foo.config;

    @Configuration
    @ComponentScan(basePackages="com.foo",
        excludeFilters=@Filter(value=ANNOTATION_TYPE, type=Configuration.class);
    public class AppConfig {
        // ...
    }

This is obviously more verbose and cumbersome than would be desirable,
and furthermore potentially too constraining as it prohibits the ability
to include other legitimate @Configuration classes via scanning.

The exception was being thrown because of a logic problem in
ClassPathBeanDefinitionScanner.  The bean definition for AppConfig gets
registered once by the user (e.g. when constructing an
AnnotationConfigApplicationContext), then again when performing the
component scan for 'com.foo'. Prior to this change,
ClassPathBeanDefinitionScanner's #isCompatible returned false if the new
bean definition was anything other than an AnnotatedBeanDefinition.  The
intention of this check is really to see whether the new bean definition
is a *scanned* bean definition, i.e. the result of a component-scanning
operation.  If so, then it becomes safe to assume that the original bean
definition is the one that should be kept, as it is the one explicitly
registered by the user.

Therefore, the fix is as simple as narrowing the instanceof check from
AnnotatedBeanDefinition to its ScannedGenericBeanDefinition subtype.

Note that this commit partially reverts changes introduced in SPR-8307
that explicitly caught ConflictingBeanDefinitionExceptions when
processing recursive @ComponentScan definitions, and rethrew as a
"CircularComponentScanException.  With the changes in this commit,
such CBDEs will no longer occur, obviating the need for this check and
for this custom exception type altogether.

Issue: SPR-8808, SPR-8307

Remove all convenience variants of #findAllAnnotationAttributes and
refactor the remaining method to accept a MetadataReaderFactory
instead of creating its own SimpleMetadataReaderFactory internally.
This allows clients to use non-default class loaders as well as
customize the particular MetadataReaderFactory to be used (e.g.
'simple' vs 'caching', etc).

Issue: SPR-8752

Issue: SPR-8411, SPR-8494

Prior to this change, @EnableTransactionManagement (via the
ProxyTransactionManagementConfiguration class) did not properly
register its auto-proxy creator through the usual AopConfigUtils
methods.  It was trying to register the APC as a normal @Bean method,
but this causes issues (SPR-8494) with the logic in
AopConfigUtils#registerOrEscalateApcAsRequired, which expects the APC
bean definition to have a beanClassName property.  When the APC is
registered via a @Bean definition, it is actually a
factoryBean/factoryMethod situation with no directly resolvable
beanClass/beanClassName.

To solve this problem, ImportSelector#selectImports has been refactored
to accept an ImportSelector.Context instance. This object contains the
AnnotationMetadata of the importing class as well as the enclosing
BeanDefinitionRegistry to allow for the kind of conditional bean
registration necessary here. In this case, the bean definition that
must be registered conditionally is that of the auto-proxy creator.
It should only be registered if AdviceMode == PROXY, and thus the
ImportSelector is an appropriate place to make this happen.  It must
happen as a BeanDefinition (rather than a @Bean method) for
compatibility with AopConfigUtils, and working with the
BeanDefinitionRegistry API allows for that. This change does mean that
in certain cases like this one, #selectImports has container modifying
side effects. Documentation has been updated to reflect.

Issue: SPR-8411, SPR-8494

Issue: SPR-8442

Issue: SPR-8314

The following is now possible:

@Configuration
public class AppConfig {
    @Inject DataSource dataSource;

    @Bean
    public MyBean myBean() {
        return new MyBean(dataSource);
    }

    @Configuration
    static class DatabaseConfig {
        @Bean
        DataSource dataSource() {
            return new EmbeddedDatabaseBuilder().build();
        }
    }
}

public static void main(String... args) {
    AnnotationConfigApplicationContext ctx =
        new AnnotationConfigApplicationContext(AppConfig.class);
    ctx.getBean(MyBean.class);     // works
    ctx.getBean(DataSource.class); // works
}

Notice that the @Import annotation was not used and that only AppConfig
was registered against the context. By virtue of the fact that
DatabaseConfig is a member class of AppConfig, it is automatically
registered when AppConfig is registered. This avoids an awkward and
redundant @Import annotation when the relationship is already implicitly
clear.

See @Configuration Javadoc for details.

Issue: SPR-8186

Revert signature of
ConfigurationClassPostProcessor#processConfigBeanDefinitions to its form
found in the 3.0.x line.  Refactorings made during 3.1 development
caused otherwise package-private types such as
ConfigurationClassBeanDefinitionReader to escape through this public
method, causing issues for STS as well as being a general design issue.

Upon review, the refactorings could easily be backed out in favor of a
simpler approach, and this has been done.

This also means that ConfigurationClassBeanDefinitionReader can return
to package-private visibility, and this change has been made as well.

Issue: SPR-8200

Allows a convenient mechanism for contributing a PropertySource to the
enclosing Spring Environment. See @PropertySource Javadoc for
complete details and PropertySourceAnnotationTests for examples.

Issue: SPR-8314

Prior to this change, @ComponentScan annotations were only processed at
the first level of depth.  Now, the set of bean definitions resulting
from each declaration of @ComponentScan is checked for configuration
classes that declare @ComponentScan, and recursion is performed as
necessary.

Cycles between @ComponentScan declarations are detected as well. See
CircularComponentScanException.

Issue: SPR-8307

Allows @Enable* a layer of indirection for deciding which @Configuration
class(es) to @Import.

The @Import annotation may now accept @Configuration class literals
and/or ImportSelector class literals.

@Configuration classes may implement ImportAware in order to be injected
with the AnnotationMetadata of their @Import'ing class.

Includes the introduction of a new PriorityOrdered
ImportAwareBeanPostProcessor that handles injection of the
importing class metadata.

Includes the introduction of AnnotationUtils#findAllAnnotationAttributes
to support iterating through all annotations declared on a given type
and interrogating each for the presence of a meta-annotation. See tests
for details.

Issue: SPR-8031, SPR-7508, SPR-8057

* Environment now extends PropertyResolver
* Environment no longer exposes resolver and sources
* PropertySource is String,Object instead of String,String
* PropertySource no longer assumes enumerability of property names
* Introduced EnumerablePropertySource for those that do have enumerable property names

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.

'default' is now a reserved profile name, indicating
that any beans defined within that profile will be registered
unless another profile or profiles have been activated.

Examples below are expressed in XML, but apply equally when
using the @Profile annotation.

EXAMPLE 1:

        <beans>
            <beans profile="default">
                <bean id="foo" class="com.acme.EmbeddedFooImpl"/>
            </beans>
            <beans profile="production">
                <bean id="foo" class="com.acme.ProdFooImpl"/>
            </beans>
        </beans>

    In the case above, the EmbeddedFooImpl 'foo' bean will be
    registered if:
        a) no profile is active
        b) the 'default' profile has explicitly been made active

    The ProdFooImpl 'foo' bean will be registered if the 'production'
    profile is active.

EXAMPLE 2:

        <beans profile="default,xyz">
            <bean id="foo" class="java.lang.String"/>
        </beans>

    Bean 'foo' will be registered if any of the following are true:
        a) no profile is active
        b) 'xyz' profile is active
        c) 'default' profile has explicitly been made active
        d) both (b) and (c) are true

Note that the default profile is not to be confused with specifying no
profile at all.  When the default profile is specified, beans are
registered only if no other profiles are active; whereas when no profile
is specified, bean definitions are always registered regardless of which
profiles are active.

The default profile may be configured programmatically:

    environmnent.setDefaultProfile("embedded");

or declaratively through any registered PropertySource, e.g. system properties:

    -DdefaultSpringProfile=embedded

Assuming either of the above, example 1 could be rewritten as follows:

        <beans>
            <beans profile="embedded">
                <bean id="foo" class="com.acme.EmbeddedFooImpl"/>
            </beans>
            <beans profile="production">
                <bean id="foo" class="com.acme.ProdFooImpl"/>
            </beans>
        </beans>

It is unlikely that use of the default profile will make sense in
conjunction with a statically specified 'springProfiles' property.
For example, if 'springProfiles' is specified as a web.xml context
param, that profile will always be active for that application,
negating the possibility of default profile bean definitions ever
being registered.

The default profile is most useful for ensuring that a valid set of
bean definitions will always be registered without forcing users
to explictly specify active profiles.  In the embedded vs. production
examples above, it is assumed that the application JVM will be started
with -DspringProfiles=production when the application is in fact in
a production environment.  Otherwise, the embedded/default profile bean
definitions will always be registered.

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.

RESOLVED - issue SPR-6779: imported @Configuration classes do not get enhanced and fail to satisfy scoping requirements
refactoring, polishing.

Resolved SPR-6618. Restrictions were too tight on overloaded bean methods and were preventing it altogether.  Overloading is now allowed, as long as there is no ambiguity at runtime which bean method should be invoked.

AnnotationMetadata returns Class values by default (again), allowing for explicit retrieval of String class names where preferred (SPR-5827)