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.
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
Since the introduction of the AnnotationConfig(Web)ApplicationContext
types in Spring 3.0, it has been possible to specify a custom
bean name generation strategy via the #setBeanNameGenerator methods
available on each of these classes.
If specified, that BeanNameGenerator was delegated to the underlying
AnnotatedBeanDefinitionReader and ClassPathBeanDefinitionScanner. This
meant that any @Configuration classes registered or scanned directly
from the application context, e.g. via #register or #scan methods would
respect the custom name generation strategy as intended.
However, for @Configuration classes picked up via @Import or implicitly
registered due to being nested classes would not be aware of this
strategy, and would rather fall back to a hard-coded default
AnnotationBeanNameGenerator.
This change ensures consistent application of custom BeanNameGenerator
strategies in the following ways:
- Introduction of AnnotationConfigUtils#CONFIGURATION_BEAN_NAME_GENERATOR
singleton
If a custom BeanNameGenerator is specified via #setBeanNameGenerator
the AnnotationConfig* application contexts will, in addition to
delegating this object to the underlying reader and scanner, register
it as a singleton bean within the enclosing bean factory having the
constant name mentioned above.
ConfigurationClassPostProcessor now checks for the presence of this
singleton, falling back to a default AnnotationBeanNameGenerator if
not present. This singleton-based approach is necessary because it is
otherwise impossible to parameterize CCPP, given that it is
registered as a BeanDefinitionRegistryPostProcessor bean definition
in AnnotationConfigUtils#registerAnnotationConfigProcessors
- Introduction of ConfigurationClassPostProcessor#setBeanNameGenerator
As detailed in the Javadoc for this new method, this allows for
customizing the BeanNameGenerator via XML by dropping down to direct
registration of CCPP as a <bean> instead of using
<context:annotation-config> to enable @Configuration class
processing.
- Smarter defaulting for @ComponentScan#beanNameGenerator
Previously, @ComponentScan's #beanNameGenerator attribute had a
default value of AnnotationBeanNameGenerator. The value is now the
BeanNameGenerator interface itself, indicating that the scanner
dedicated to processing each @ComponentScan should fall back to an
inherited generator, i.e. the one originally specified against the
application context, or the original default provided by
ConfigurationClassPostProcessor. This means that name generation
strategies will be consistent with a single point of configuration,
but that individual @ComponentScan declarations may still customize
the strategy for the beans that are picked up by that particular
scanning.
Issue: SPR-9124
Prior to this commit, and based on earlier changes supporting SPR-9023,
ConfigurationClassBeanDefinitionReader employed a simplistic strategy
for extracting the 'value' attribute (if any) from @Configuration in
order to determine the bean name for imported and nested configuration
classes. An example case follows:
@Configuration("myConfig")
public class AppConfig { ... }
This approach is too simplistic however, given that it is possible in
'configuration lite' mode to specify a @Component-annotated class with
@Bean methods, e.g.
@Component("myConfig")
public class AppConfig {
@Bean
public Foo foo() { ... }
}
In this case, it's the 'value' attribute of @Component, not
@Configuration, that should be consulted for the bean name. Or indeed if
it were any other stereotype annotation meta-annotated with @Component,
the value attribute should respected.
This kind of sophisticated discovery is exactly what
AnnotationBeanNameGenerator was designed to do, and
ConfigurationClassBeanDefinitionReader now uses it in favor of the
custom approach described above.
To enable this refactoring, nested and imported configuration classes
are no longer registered as GenericBeanDefinition, but rather as
AnnotatedGenericBeanDefinition given that AnnotationBeanNameGenerator
falls back to a generic strategy unless the bean definition in question
is assignable to AnnotatedBeanDefinition.
A new constructor accepting AnnotationMetadata
has been added to AnnotatedGenericBeanDefinition in order to support
the ASM-based approach in use by configuration class processing. Javadoc
has been updated for both AnnotatedGenericBeanDefinition and its now
very similar cousin ScannedGenericBeanDefinition to make clear the
semantics and intention of these two variants.
Issue: SPR-9023
Prior to this commit, an infinite recursion would occur if a
@Configuration class were nested within its superclass, e.g.
abstract class Parent {
@Configuration
static class Child extends Parent { ... }
}
This is because the processing of the nested class automatically
checks the superclass hierarchy for certain reasons, and each
superclass is in turn checked for nested @Configuration classes.
The ConfigurationClassParser implementation now prevents this by
keeping track of known superclasses, i.e. once a superclass has been
processed, it is never again checked for nested classes, etc.
Issue: SPR-8955
Prior to changes in commit 57851de88e,
AbstractResource#getFilename threw IllegalStateException unless
overridden by a subclass. Following that change, this method now throws
null instead, but ResourceTests#testAbstractResourceExceptions had not
been updated to reflect, resulting in a false negative failure. This has
now been fixed.
Issue: SPR-9043
Eclipse allows autoboxing on type inference; Sun javac does not. This
means that variables assigned from calls to
AnnotationAttributes#getNumber should consistently use object wrappers
as opposed to number primitives. There was only one such instance
anyway, and has now been updated accordingly.
Prior to JDK 7, java.beans.Introspector registered indexed write methods
irrespective of return type, for example either of the following methods
were legal
void setFoo(int i, Foo foo)
Object setFoo(int i, Foo foo)
This was considered a bug and disallowed starting with JDK 7, such that
only the former signature is a candidate.
Supporting non-void returning setter methods is exactly what
ExtendedBeanInfo was designed to do, and prior to this commit, the
implementation of ExtendedBeanInfo assumed this (somewhat surprising)
behavior from the underlying Introspector, and because it worked out of
the box, took no extra steps to recognize and register these methods.
For this reason, non-void returning indexed write methods were not
registered under JDK 7+, causing test failures in ExtendedBeanInfoTests.
Now the implementation is careful to detect these methods without any
assumption about Introspector behavior, such that they are registered in
exactly the same fashion across JDK versions.
Issue: SPR-9014
Prior to this commit, ExtendedBeanInfo would add non-indexed write
methods without consideration for the presence of indexed read/write
methods, which is invalid per the JavaBeans spec and per the behavior
of java.beans.Introspector. That is, a method with the signature
void setFoo(Foo foo)
Should never be registered as a write method if the following method
signature is also present in the class
void setFoo(int i, Foo foo)
In most cases, this oversight caused no problems, but in certain
situations where a bean actually contains such a mismatch of methods,
"type mismatch" errors were thrown when ExtendedBeanInfo attempted the
illegal addition against the underlying property descriptor.
The implementation is now more careful about checking the parameter type
of write methods -- if the property descriptor in question is an
IndexedPropertyDescriptor, i.e. has an indexed write method, then any
non-indexed write method candidate must have a single *array* parameter,
which conforms to the spec and to Introspector behavior.
Issue: SPR-8937
- Drop 'expectedType' parameter from #getClass and #getEnum methods and
rely on compiler inference based on type of assigned variable, e.g.
public @interface Example {
Color color();
Class<? extends UserType> userType();
int order() default 0;
}
AnnotationAttributes example =
AnnotationUtils.getAnnotationAttributes(Example.class, true, true);
Color color = example.getEnum("color");
Class<? extends UserType> userType = example.getClass("userType");
or in cases where there is no variable assignment (and thus no
inference possible), use explicit generic type, e.g.
bean.setColor(example.<Color>getEnum("color"));
- Rename #get{Int=>Number} and update return type from int to
<N extends Number>, allowing invocations such as:
int order = example.getNumber("order");
These changes reduce the overall number of methods exposed by
AnnotationAttributes, while at the same time providing comprehensive
access to all possible annotation attribute types -- that is, instead of
requiring explicit #getInt, #getFloat, #getDouble methods, the
single #getNumber method is capabable of handling them all, and without
any casting required. And the obvious additional benefit is more concise
invocation as no redundant 'expectedType' parameters are required.
Recent changes in ExtendedBeanInfo involve invoking
ClassUtils#getMostSpecificMethod when determining JavaBeans get/set
pairs; if Java security settings control disallow reflective access,
this results in an AccessControlException.
This change defends against this (comparatively rare) scenario by
catching the exception and falling back to returning the method
originally supplied by the user.
This change was a result of noticing CallbacksSecurityTests failing
following the ExtendedBeanInfo modifications mentioned above
Issue: SPR-8949
The username is usually not null, but it could be for some embedded databases.
Always setting generatedKeysColumnNameArraySupported to false when getGeneratedKeysSupported is false, since it can't be supported without having generated keys supported. This change only affects logging messages.
Issue: SPR-9006
Adding a static CustomSQLExceptionTranslatorRegistry and a CustomSQLExceptionTranslatorRegistrar that can be used to register custom SQLExceptionTranslator implementations for specific databases from any application context.
This can be used in application contexts like this:
<bean class="org.springframework.jdbc.support.CustomSQLExceptionTranslatorRegistrar">
<property name="sqlExceptionTranslators">
<map>
<entry key="H2">
<bean class="com.yourcompany.data.CustomSqlExceptionTranslator"/>
</entry>
</map>
</property>
</bean>
Issue: SPR-7675
Prior to this commit, and due to idiosyncracies of
java.beans.Introspector, overridden boolean getter methods were not
detected by Spring's ExtendedBeanInfo, which relied on too-strict
Method equality checks when selecting read and write methods.
Now ExtendedBeanInfo uses Spring's ClassUtils#getMostSpecificMethod
against the methods returned from java.beans.Introspector in order
to ensure that subsequent equality checks are reasonable to make.
Issue: SPR-8949
ServletServerHttpRequest now falls back on the contentType and the
the characterEncoding of the ServletRequest, if the headers of the
incoming request don't specify one. Similary ServletServerHttpResponse
sets the contentType and the characterEncoding of the ServletResponse
if not already set.
This allows using the CharacterEncodingFilter to set a character
encoding where the request doesn't specify one and have it be used
in HttpMessageConverter's.
SPR-9096
Although the reference documentation listed the new @MVC support
classes and their benefits, it did not explicitly mention a few
use cases that are no longer supported. There is now a specific
section on the new support classes listing exactly what is not
supported.
Similary the @RequestMapping annotation never refered explicitly
to the existence of old and new support and never made it clear
exactly what the differences are.
Both have not been corrected.
SPR-9063, SPR-9042
Uses of AnnotationMetadata#getAnnotationAttributes throughout the
framework have been updated to use the new AnnotationAttributes API in
order to take advantage of the more concise, expressive and type-safe
methods there.
All changes are binary compatible to the 3.1.0 public API, save
the exception below.
A minor binary compatibility issue has been introduced in
AbstractCachingConfiguration, AbstractAsyncConfiguration and
AbstractTransactionManagementConfiguration when updating their
protected Map<String, Object> fields representing annotation attributes
to use the new AnnotationAttributes API. This is a negligible breakage,
however, as the likelilhood of users subclassing these types is very
low, the classes have only been in existence for a short time (further
reducing the likelihood), and it is a source-compatible change given
that AnnotationAttributes is assignable to Map<String, Object>.
Background
Spring 3.1 introduced the @ComponentScan annotation, which can accept
an optional array of include and/or exclude @Filter annotations, e.g.
@ComponentScan(
basePackages = "com.acme.app",
includeFilters = { @Filter(MyStereotype.class), ... }
)
@Configuration
public class AppConfig { ... }
@ComponentScan and other annotations related to @Configuration class
processing such as @Import, @ImportResource and the @Enable*
annotations are parsed using reflection in certain code paths, e.g.
when registered directly against AnnotationConfigApplicationContext,
and via ASM in other code paths, e.g. when a @Configuration class is
discovered via an XML bean definition or when included via the
@Import annotation.
The ASM-based approach is designed to avoid premature classloading of
user types and is instrumental in providing tooling support (STS, etc).
Prior to this commit, the ASM-based routines for reading annotation
attributes were unable to recurse into nested annotations, such as in
the @Filter example above. Prior to Spring 3.1 this was not a problem,
because prior to @ComponentScan, there were no cases of nested
annotations in the framework.
This limitation manifested itself in cases where users encounter
the ASM-based annotation parsing code paths AND declare
@ComponentScan annotations with explicit nested @Filter annotations.
In these cases, the 'includeFilters' and 'excludeFilters' attributes
are simply empty where they should be populated, causing the framework
to ignore the filter directives and provide incorrect results from
component scanning.
The purpose of this change then, is to introduce the capability on the
ASM side to recurse into nested annotations and annotation arrays. The
challenge in doing so is that the nested annotations themselves cannot
be realized as annotation instances, so must be represented as a
nested Map (or, as described below, the new AnnotationAttributes type).
Furthermore, the reflection-based annotation parsing must also be
updated to treat nested annotations in a similar fashion; even though
the reflection-based approach has no problem accessing nested
annotations (it just works out of the box), for substitutability
against the AnnotationMetadata SPI, both ASM- and reflection-based
implementations should return the same results in any case. Therefore,
the reflection-based StandardAnnotationMetadata has also been updated
with an optional 'nestedAnnotationsAsMap' constructor argument that is
false by default to preserve compatibility in the rare case that
StandardAnnotationMetadata is being used outside the core framework.
Within the framework, all uses of StandardAnnotationMetadata have been
updated to set this new flag to true, meaning that nested annotation
results will be consistent regardless the parsing approach used.
Spr9031Tests corners this bug and demonstrates that nested @Filter
annotations can be parsed and read in both the ASM- and
reflection-based paths.
Major changes
- AnnotationAttributes has been introduced as a concrete
LinkedHashMap<String, Object> to be used anywhere annotation
attributes are accessed, providing error reporting on attribute
lookup and convenient type-safe access to common annotation types
such as String, String[], boolean, int, and nested annotation and
annotation arrays, with the latter two also returned as
AnnotationAttributes instances.
- AnnotationUtils#getAnnotationAttributes methods now return
AnnotationAttributes instances, even though for binary compatibility
the signatures of these methods have been preserved as returning
Map<String, Object>.
- AnnotationAttributes#forMap provides a convenient mechanism for
adapting any Map<String, Object> into an AnnotationAttributes
instance. In the case that the Map is already actually of
type AnnotationAttributes, it is simply casted and returned.
Otherwise, the map is supplied to the AnnotationAttributes(Map)
constructor and wrapped in common collections style.
- The protected MetadataUtils#attributesFor(Metadata, Class) provides
further convenience in the many locations throughout the
.context.annotation packagage that depend on annotation attribute
introspection.
- ASM-based core.type.classreading package reworked
Specifically, AnnotationAttributesReadingVisitor has been enhanced to
support recursive reading of annotations and annotation arrays, for
example in @ComponentScan's nested array of @Filter annotations,
ensuring that nested AnnotationAttributes objects are populated as
described above.
AnnotationAttributesReadingVisitor has also been refactored for
clarity, being broken up into several additional ASM
AnnotationVisitor implementations. Given that all types are
package-private here, these changes represent no risk to binary
compatibility.
- Reflection-based StandardAnnotationMetadata updated
As described above, the 'nestedAnnotationsAsMap' constructor argument
has been added, and all framework-internal uses of this class have
been updated to set this flag to true.
Issue: SPR-7979, SPR-8719, SPR-9031
Ensure that both FlashMapManager methods - the one invoked at the
start of a request and the one invoked before a redirect, update
the underlying storage fully since it's not guaranteed that both
will be invoked on any given request.
Also move the logic to remove expired FlashMap instances to the
metohd invoked at the start of a request to ensure the check is
made frequently enough.
SPR-8997
Prior to this change, single quotes were incorrectly parsed by
NamedParameterUtils#parseSqlStatement, resulting in incorrect parameter
counts:
ParsedSql sql = NamedParameterUtils
.parseSqlStatement("SELECT 'foo''bar', :xxx FROM DUAL");
assert sql.getTotalParameterCount() == 0 // incorrect, misses :xxx
That is, presence of the single-quoted string caused the parser to
overlook the named parameter :xxx.
This commit fixes the parsing error such that:
ParsedSql sql = NamedParameterUtils
.parseSqlStatement("SELECT 'foo''bar', :xxx FROM DUAL");
assert sql.getTotalParameterCount() == 1 // correct
Issue: SPR-8280
ResourceDatabasePopulator is a component that underlies the database
initialization support within Spring's jdbc: namespace, e.g.:
<jdbc:initialize-database data-source="dataSource">
<jdbc:script execution="INIT" location="classpath:init.sql"/>
</jdbc:initialize-database>
Prior to this commit, ResourceDatabasePopulator#executeSqlScript's use
of Statement#executeUpdate(sql) precluded the possibility of SELECT
statements because returning a result is not permitted by this method
and results in an exception being thrown.
Whether this behavior is a function of the JDBC specification or an
idiosyncracy of certain implementations does not matter as the issue
can be worked around entirely. This commit eliminates use
of #executeUpdate(sql) in favor of #execute(sql) followed by a call
to #getUpdateCount, effectively allowing any kind of SQL statement to
be executed during database initialization.
Issue: SPR-8932
Prior to this commit, StandardServletEnvironment's servlet context
PropertySource remained stubbed out until it the ServletContext became
available and could be replaced during the refresh() of its enclosing
WebApplicationContext. This behavior is acceptable in most cases.
However, if the user has declared an ApplicationContextInitializer that
attempts to access servlet context-params via the Environment API, this
result in a kind of 'false negative', i.e. the context-param key and
value are actually present in the ServletContext, but the PropertySource
representing servlet context params is still a stub at this point,
meaning that it returns an empty result in all cases.
With this change, WebApplicationContextUtils#initServletPropertySources
is invoked eagerly by the ContextLoader if any ACI classes have been
declared. This swaps out the servlet context property source stub for
the real thing just in time for ACIs to use it if necessary.
Extra guard logic has been added to #initServletPropertySources to
ensure idempotency -- once the stub has been replaced, the method
never attempts the replacement again, e.g. during the normal context
refresh() when this method will be called again.
Issue: SPR-8991
- Perform early check whether any ACI classes have been declared and
exit immediately if not, avoiding any other processing
- Polish method names in ContextLoaderTests
Issue: SPR-8991
The spring-aspects Maven pom had an incorrect compile-scoped dependence
on spring-test. In fact, spring-aspects only uses spring-test in its
unit tests. The pom has been updated accordingly, meaning that use
of spring-aspects in Maven-based applications will no longer require
spring-test on the classpath at runtime.
ivy.xml metadata did not need updating, as it was already correct.
This change is only necessary on the 3.1.x line; in 3.2.x (master) Maven
poms are generated automatically from Gradle dependency metadata, which
is also already correct.
Issue: SPR-9048
A list of "known" session attributes (listed in @SessionAttributes)
was gradually built as attributes get added to the model. In a
failover scenario that knowledge is lost causing session attributes
to be potentially re-initialized via @ModelAttribute methods.
With this change @SessionAttributes listed by name are immediately
added to he list of "known" session attributes thus this knowledge
is not lost after a failover. Attributes listed by type however
still must be discovered as they get added to the model.
Prior to this commit, @Configuration classes included via @Import (or
via automatic registration of nested configuration classes) would
always be registered with a generated bean name, regardless of whether
the user had specified a 'value' indicating a customized bean name, e.g.
@Configuration("myConfig")
public class AppConfig { ... }
Now this bean name is propagated as intended in all cases, meaning that
in the example above, the resulting bean definition of type AppConfig
will be named "myConfig" regardless how it was registered with the
container -- directly against the application context, via component
scanning, via @Import, or via automatic registration of nested
configuration classes.
Issue: SPR-9023
A number of users reported issues with comparing method identity vs
equivalence when discovering JavaBeans property methods in
ExtendedBeanInfo.
This commit updates the implementation to consistently use '.equals()'
instead of '=='.
Issue: SPR-8079, SPR-8347
This issue originates from a need in Spring Data JPA, wherein a custom
InstantiationAwareBeanPostProcessor may alter the predicted type of
FactoryBean objects, effectively preventing retrieval of those beans via
calls to #getBeansOfType(FactoryBean.class).
The reason for this "masking effect" is that prior to this change, the
implementation of AbstractBeanFactory#isFactoryBean considered only the
"predicted type" returned from #predictBeanType when evaluating
assignability to FactoryBean.class
The implementation of #isFactoryBean now ensures that not only the
predicted bean type is considered, but also the original bean
definition's beanClass (if one is available).
Issue: SPR-8954
This change introduces a protected ReflectiveMethodResolver#getMethods,
allowing subclasses to specify additional static methods not
declared directly on the type being evaluated. These methods then become
candidates for filtering by any registered MethodFilters and ultimately
become available within for use within SpEL expressions.
Issue: SPR-9038
The "default" FlashMapManager implementation added in 3.1 was invoked
after the redirect, which is too late in cases where the HTTP session
has not been yet been created since as the response is committed.
This change corrects the issue and makes other improvements to the
FlashMapManager implementation such as extracting a base
AbstractFlashMapManager class and making it easier for other
implementations to be added (for example cookie-based).
When switching back to 3.1.x from master, ignore renamed directories,
Gradle 'build' dirs, generated IDE metadata, etc.
You may wish to clean these files with
$ git clean -dfx
Or do a dry-run beforehand with the '-n' flag:
$ git clean -dfxn
A direct path match with incorrect HTTP request method was causing another
request mapping with a pattern and a correct HTTP method to be ignored.
The bug affects the new @MVC support classes
(i.e. RequestMappingHandlerMapping).
It should be possible to progress from extending
WebMvcConfigurerAdapter (w/ @EnableWebMvc) to extending
WebMvcConfigurationSupport directly, to extending
DelegatingWebMvcConfigurationSupport. This change
makes that possible.
Previously flash attributes were automatically merged into the
model of annotated controllers only. This change extends the same
benefit to ParameterizableView- and UrlFilenameViewController,
both of which merely select a view without user controller logic
and (the views) would otherwise not have access to the flash
attributes.
When checking for an exact match of Accept header media types
additional parameters such as quality need to be excluded.
For example "*/*" matches "*/*;q=0.9".
- Eliminate trailing whitespace
- Update long method signatures to follow framework whitespace
conventions
Based on the following search,
$ git grep -A3 '^.public .* .*([^\{;]*$' */src/main
the strong convention throughout the framework when dealing with
methods having long signatures (i.e. many parameters) is to break
immediately after the opening paren, indent two tabs deeper and break
lines around 90 characters as necessary. Such signatures should also
be followed by a newline after the opening curly brace to break
things up visually.
The files edited in this commit had a particularly different style of
intenting arguments to align with each other vertically, but the
alignment only worked if one's tabstop is set at four spaces.
When viewed at a different tabstop value, the effect is is jarring,
both in that it is misaligned and significantly different from most
of the framework. The convention described above reads well at any
tabstop value.
Before this change, flash attributes could only be added if via
RedirectAttributes.addFlashAttribute(..) if the method returned
a view name or a View instance. With this change, the above is
supported with a ModelAndView return value as well.
Prior to this change, the spring-cache XSD allowed a 'key-generator'
attribute, but it was not actually parsed by AnnotationDrivenCacheBDP.
This commit adds the parsing logic as originally intended and the test
to prove it.
Issue: SPR-8939
Prior to this change, the caching reference docs referred to
'root.params', whereas the actual naming should be 'root.args'. This
naming was also reflected in the "#p" syntax for specifying method args.
This change updates the documentation to refer to 'root.args' properly
and also adds "#a" syntax for specifying method arguments more
intuitively. Note that "#p" syntax remains in place as an alias for
backward compatibility.
Issue: SPR-8938
Prior to this change, roughly 5% (~300 out of 6000+) of files under the
source tree had CRLF line endings as opposed to the majority which have
LF endings.
This change normalizes these files to LF for consistency going forward.
Command used:
$ git ls-files | xargs file | grep CRLF | cut -d":" -f1 | xargs dos2unix
Issue: SPR-5608
spring-build was previously included via an svn:external. Adding
directly to the source tree under Git to avoid the need for a git
submodule.
In order to build from any earlier commit, it is recommended to
export spring-build or symlink an existing copy into the root
of the spring-framework project and then build normally.
$ svn export https://src.springsource.org/svn/spring-build/tags/project-build-2.5.2 spring-build
Prior to this fix, ContextLoader(Listener)'s would overwrite any
value set directly against a WebApplicationContext's #setConfigLocation
method. This is a likely scenario when using Spring 3.1's new
WebApplicationInitializer support.
Now a check is performed to ensure that the ContextLoader init-param
value is non-null before doing the overwriting.
Added tests to ensure that all expected precedence, overwriting and
defaulting of context config locations works as expected.
Issue: SPR-8510
Prior to this change, ScheduledAnnotationBeanPostProcessor found any
@Scheduled methods against the ultimate targetClass for a given bean
and then attempted to invoke that method against the bean instance. In
cases where the bean instance was in fact a JDK proxy, this attempt
would fail because the proxy is not an instance of the target class.
Now SABPP still attempts to find @Scheduled methods against the target
class, but subsequently checks to see if the bean is a JDK proxy, and if
so attempts to find the corresponding method on the proxy itself. If it
cannot be found (e.g. the @Scheduled method was declared only at the
concrete class level), an appropriate exception is thrown, explaining to
the users their options: (a) use proxyTargetClass=true and go with
subclass proxies which won't have this problem, or (b) pull the
@Scheduled method up into an interface.
Issue: SPR-8651
Prior to this change, an assumption was made in
AbstractAutowireCapableBeanFactory that any factory-method would have
zero parameters. This may not be the case in @Bean methods.
We now look for the factory-method by name in a more flexible fashion
that accomodates the possibility of method parameters.
There remains at least one edge cases here where things could still fail,
for example a @Configuration class could have two FactoryBean-returning
methods of the same name, but each with different generic FactoryBean
types and different parameter lists. In this case, the implementation
may infer and return the wrong object type, as it currently returns
the first match for the given factory-method name. The complexity cost
of ensuring that this never happens is not likely worth the trouble
given the very low likelihood of such an arrangement.
Issue: SPR-8762
In order to determine why classloading errors occur after
upgrading to 4.2.0.Final.
To demonstrate this error, uncomment the 4.2.0.Final dependency in
ivy.xml and run `ant test` within the .web.servlet module.
In order to determine why Ehcache classloading errors occur after
upgrading to 4.2.0.Final.
To demonstrate this error, uncomment the 4.2.0.Final dependency in
ivy.xml and run `ant test` within the .context module.
From earlier dependence on 4.0.0.CR4.
Spring 3.1.x will upgrade to Hibernate 4.0.0.Final as soon as possible
after its release.
Pom files have also been updated to 'recommend' use of Hibernate
3.6.0.Final or better (earlier value was 3.3.1.GA).
aspectjrt is a subset of aspectjweaver. Eliminate mentions of aspectjrt
where aspectjweaver is already necessary (e.g. LTW), and do not mention
aspectjweaver where only aspectrt is required (e.g. @Aspect proxying)
Also bump required version of aspect* libs from 1.5 to 1.6.8, reflecting
OSGi and pom metadata.
Issue: SPR-8896
Prior to this change, to specify two or more annotation include/exclude
filters, one would declare @ComponentScan as follows:
@ComponentScan(basePackages="example.scannable",
useDefaultFilters=false,
includeFilters={
@Filter(MyStereotype.class),
@Filter(MyComponent.class)
})
This was because @Filter's 'value' attribute accepted exactly one
argument.
Now, any given @Filter may accept one or more value arguments, allowing
for more concise @ComponentScan declarations:
@ComponentScan(basePackages="example.scannable",
useDefaultFilters=false,
includeFilters=@Filter({MyStereotype.class, MyComponent.class}))
Supplying multiple arguments in this way assumes that they are the same
type of filter, e.g. ANNOTATION, ASSIGNABLE_TYPE, or CUSTOM. To declare
multiple *different* types of filters, multiple @Filter annotations are
still required, e.g.:
@ComponentScan(
includeFilters={
@Filter(type=ANNOTATION, value=MyStereotype.class),
@Filter(type=ASSIGNABLE_TYPE, value={Foo.class, Bar.class})
})
Note that specifying zero arguments, e.g. @Filter({}) is nonsensical; it
will have no effect on component scanning, but does not raise an error.
Issue: SPR-8881
For clarity, add @Target({}) to definition of @Filter, constraining it
to complex annotation composition only; i.e. it cannot be placed on
any element, only within annotations, e.g.
@ComponentScan(includeFilters=@Filter(...))
is legal, while
@Filter
public class MyType { }
is not.
Also, widen @Retention from SOURCE to RUNTIME, even though it is not
technically necessary, as all parsing of @Filter annotations happens via
ASM, i.e. at the source level. This change is made primarily for
consistency (@ComponentScan's Retention is RUNTIME) and in avoidance of
potential confusion or surprise on the part of those casually browsing
the code.
This method allows a view to access the combined context path and
servlet mapping path for prefixing URLs without having to specify
the literal part of a servlet mapping such as "/main/*")
explicitly everywhere. For example:
${requestContext.pathToServlet}/css/main.css
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
The AbstractHttpMessageConverter was using the requested Content-Type
rather than the actual response Content-Type to determine the length
of the content. This can lead to a problem when a controller returns
a ResponseEntity with a Content-Type header that ignores (overrides)
the requested Content-Type. The fix ensures that actual response
Content-Type is the one used both to write to the response and to
determine the length of the content.
Equivalent to <context:spring-configured/>.
Also update @EnableLoadTimeWeaving Javadoc and spring-configured XSD
documentation to reflect.
Issue: SPR-7888
3.1 M2 introduced a regression that causes false positives during
@Configuration class candidate checks. Now performing a call to
AnnotationMetadata#isInterface in addition to checks for @Component and
@Bean annotations when determining whether a candidate is a 'lite'
configuration class. Annotations are in the end interfaces, so both
are filtered out at once.
Issue: SPR-8761
Prior to this change, any instantiation of an
AnnotationConfigApplicationContext would trigger the creation of three
StandardEnvironment objects: one for the ApplicationContext, one for the
AnnotatedBeanDefinitionReader, and one for the
ClassPathBeanDefinitionScanner.
The latter two are immediately swapped out when the ApplicationContext
delegates its environment to these subordinate objects anyway. Not only
is it inefficient to create these two extra Environments, it creates
confusion when debug-level logging is turned on. From the user's
perspective and in practice, there is only one Environment; logging
should reflect that.
This change ensures that only one Environment object is ever created for
a given ApplicationContext. If an AnnotatedBeanDefinitionReader or
ClassPathBeanDefinitionScanner are used in isolation, e.g. against a
plain BeanFactory/BeanDefinitionRegistry, then they will still create
their own local StandardEnvironment object.
All public API compatibility is preserved; new constructors have been
added where necessary to accommodate passing an Environment directly
to ABDR ar CPBDS.
Properties such as 'spring.profiles.active' cannot be specified at the
command line under Bash and other shells due to variable naming
constraints. This change allows for exchanging underscores for periods
as well as capitalizing property names for more idiomatic naming when
dealing with environment variables.
For example, Spring will respect equally either of the following:
spring.profiles.active=p1 java -classpath ... MyApp
SPRING_PROFILES_ACTIVE=p1 java -classpath ... MyApp
The former is not possible under Bash, while the latter is. No code or
configuration changes are required; SystemEnvironmentPropertySource
adapts for these varations automatically.
SystemEnvironmentPropertySource is added by default as
"systemEnvironment" to StandardEnvironment and all subtypes, taking the
place of the plain MapPropertySource that was in use before this change.
Issue: SPR-8869
Allowing beans of primitive type to be looked up via getBean(Class), or
to be injected using @Autowired or @Injected or @Resource. Prior to
these changes, an attempt to lookup or inject a bean of, for example,
type boolean would fail because all spring beans are Objects, regardless
of initial type due to the way that ObjectFactory works.
Now these attempts to lookup or inject primitive types work, thanks to
simple changes in AbstractBeanFactory using ClassUtils#isAssignable
methods instead of the built-in Class#isAssignableFrom. The former takes
into account primitives and their object wrapper types, whereas the
latter does not.
The need to declare, look up or inject primitive-typed beans is probably
low -- how often does one need a bean of type boolean or int after all?.
Prior to the introduction of @Bean methods in Spring 3.0, it was not
possible in practice to register primitive beans, so this issue never
came up. Now that one can declare primitive-typed beans, it does make
sense that we properly support by-type lookup and injection without
forcing the user to work with object wrappers.
Issue: SPR-8874
Currently the combine method consolidates "/*" and "/hotel"
into "/hotel". However if the first pattern contains URI template
variables, the consolidation seems wrong. The fix is to prevent
the consolidation if the first pattern contains "{".
Certain edge cases around return type covariance can trigger an
IntrospectionException when trying to create a new PropertyDescriptor;
particularly around the addition of write methods with parameter types
that do not match read method return types.
These type mismatch exceptions are raised during normal Introspector
operations as well (i.e. without ExtendedBeanInfo in the mix), but
the Introspector intentionally supresses them. In covariance cases,
there is often already a suitable write method present, e.g. discovered
in a supertype or superinterface, that, with the benefit of bridge
methods works just fine in practice at runtime. That is to say, in
these suppression cases, the rejection of the write method is 'OK' in
that there is already a write method present that can handle a call.
ExtendedBeanInfo now mirrors this suppression behavior, but does issue
a WARN-level log message to let the user know.
An important effect of this change is that ExtendedBeanInfo now modifies
the delegate BeanInfo object, whereas previously it did not. In practice
this probably matters very little, but it is a design change worth
noting. The reason for this change was to avoid the need to create new
PropertyDescriptors wherever possible. It was discovered that by updating
existing PDs, one can avoid these IntrospectionExceptions a greater
percentage of the time.
Issue: SPR-8806
The UriComponentsBuilder instance passed into the method is initialized
with current request information including host, scheme, port, context
path, and the servlet mapping's literal part.
Also added shortcut methods to buildAndExpand in UriComponentsBuilder.
The registration of more than one ConfigurationClassPostProcessor
results in the double-enhancement of @Configuration classes, i.e. a
two-deep CGLIB subclass hierarchy is created.
As a side-effect of changes introduced in 3.1 M2 fixing SPR-8080, this
behavior now results in an infinite loop at CGLIB callback processing
time, leading to a StackOverflowException which is then suppressed by
the container, and ultimately results in the user being presented with
an unintuitive "Bean 'x' is not already in creation" exception.
This fix introduces a marker interface 'EnhancedConfiguration' to be
implemented by all generated @Configuration subclasses. The
configuration class enhancer can then behave in an idempotent fashion
by checking to see whether a candidate @Configuration class is already
assignable to this type i.e. already enhanced and ignore it if so.
Naturally, users should avoid registering more than one
ConfigurationClassPostProcessor, but this is not always possible. As
with the case in point, SPR-8824 originates from problems with
spring-data-neo4j, which explicitly registers its own
ConfigurationClassPostProcessor. The user has little control over this
arrangement, so it is important that the framework is defensive as
described above.
Issue: SPR-8824
The initial solution kept these three in full sync at all times:
contentType field, characterEncoding field, 'Content-Type' header.
That is correct behavior, however it breaks existing tests that rely
on contentType and characterEncoding being equal to exactly what
they were set to.
For example, consider:
response.setContentType("text/plain");
response.setCharacterEncoding("UTF-8");
Ideally both contentType and the 'Content-Type' header would now be
"text/plain;charset=UTF-8". However, existing tests would expect
that contentType is equal to "text/plain".
To avoid breaking existing tests, contentType and characterEncoding
will continue to be equal to exactly what they were set to while
the 'Content-Type' header will always include both the content
type and the charset.
The only exception to this rule is when a 'Content-Type' header
is set explicitly, the contentType and characterEncoding fields will
be updated accordingly, possibly overriding the existing values.
The Content-Type header and the contentType field in HttpServletRequest/Response
are now always in sync. When a header is added the contentType field is updated
as well and vice versa.
Similarly when the Content-Type header or the contentType field includes a charset
field, the character encoding is updated and vice versa.
Separate concerns of @Configuration class selection from the need to
register certain infrastructure beans such as auto proxy creators.
Prior to this change, ImportSelector implementations were responsible
for both of these concerns, leading to awkwardness and duplication.
Also introduced in this change is ImportBeanDefinitionRegistrar and
two implementations, AutoProxyRegistrar and AspectJAutoProxyRegistrar.
See the refactored implementations of CachingConfigurationSelector,
TransactionManagementConfigurationSelector to see the former;
AspectJAutoProxyConfigurationSelector to see the latter.
ImportSelector and ImportBeanDefinitionRegistrar are both handled as
special-case arguments to the @Import annotation within
ConfigurationClassParser.
These refactorings are important because they ensure that Spring users
will be able to understand and extend existing @Enable* annotations
and their backing ImportSelector and @Configuration classes, as well
as create their own with a minimum of effort.
Also eliminate all 'cache definition' language in favor of
'cache operation' in comments, method and parameter names (most
classes had already been refactored to this effect).
Unfortunately creates a large diff due to whitespace changes as well as
false attribution of authorship from a git/svn 'blame' perspective.
Be sure to perform diffs using `git diff -w` or `svn diff -w` when
reviewing recent changes to these sources to ignore all whitespace.
In favor of existing #setCacheOperationSources(CacheOperationSource...)
Also polish Javadoc throughout, replacing stale references to
CacheDefinitionSource where appropriate as well as other minor changes
Facilitates type-safe programmatic configuration from @Bean methods:
@Bean
public CacheManager cacheManager() {
SimpleCacheManager cm = new SimpleCacheManager();
cm.setCaches(Arrays.asList(
new ConcurrentMapCache("default"),
new ConcurrentMapCache("primary"),
new ConcurrentMapCache("secondary")
));
return cm;
}
Prior to this change, the code above would have raised errors on the
Arrays.asList() call because it returns a Collection<? extends Cache>
as opposed to Collection<Cache>.
After this change, AbstractCacheManager expects
Collection<? extends Cache> throughout.
This was removed once previously but accidentally re-introduced later.
The 'correct' version of spring-cache-3.1.xsd lives in spring-context
as opposed to here in spring-context-support.
Also placed .gitignore file within src/main/resources such that the
now-empty directory does not get pruned in git environments, which will
otherwise cause 'missing source folder' errors within Eclipse/IDEA.
Refactored getConfig => getApplicationContext such that subclasses have
control over the type of ApplicationContext used by the base class
tests. Done in anticipation of @EnableCaching tests that will favor use
of AnnotationConfigApplicationContext
Also updated all use of ClassPathXmlApplictionContext to
GenericXmlApplicationContext, which is generally preferred.
There was some question about whether enabling subclass proxies via
proxyTargetClass / proxy-target-class settings would break annotation-
based demarcation of joinpoints due to inability to discover those
annotations in various scenarios. The provided tests prove that in
any conceivable case, these annotations (@Transactional, at least)
are discovered in a consistent fashion, meaning that switching proxy
strategies should be transparent to the application and honor
intended annotation semantics.
Since dynamic attributes were allowed in Spring 3, it raised the
possibility to specify a type attribute on a number of the form tags.
Where it makes sense (see below) that attribute is now rejected
and reversely where it makes sense it is accepted.
InputTag allows types other than "text" but rejects type="radio" or
type="checkbox" since there is a good reason for those to be used
only in conjunction with the appropriate form library tags.
Other HTML input tags such as PasswordTag, HiddenInputTag,
Checkbox(es)Tag and RadioBox(es)Tag check the dynamic attributes
and reject them if they contain a type attribute since.
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
Use of package private @Bean methods can cause issues if the class
is extended and the sub-class is in a different package. This is
covered in detail in SPR-8756.
Certain external javadoc links were broken or out of date, namely
Hibernate, Java SE and EE 6, Quartz, and Apache Pluto. All resolve
properly now.
Issue: SPR-8720
Add BridgeMethodResolver#isJava6VisibilityBridgeMethodPair to
distinguish between (a) bridge methods introduced in Java 6 to
compensate for inheriting public methods from non-public superclasses
and (b) bridge methods that have existed since Java 5 to accommodate
return type covariance and generic parameters.
In the former case, annotations should be looked up from the original
bridged method (SPR-7900). In the latter, the annotation should be
looked up against the bridge method itself (SPR-8660).
As noted in the Javadoc for the new method, see
http://stas-blogspot.blogspot.com/2010/03/java-bridge-methods-explained.html
for a useful description of the various types of bridge methods, as
well as http://bugs.sun.com/view_bug.do?bug_id=6342411, the bug fixed in
Java 6 resulting in the introduction of 'visibility bridge methods'.
Issue: SPR-8660, SPR-7900
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
This commit and the several before it back out the
SessionFactoryBuilder and AnnotationSessionFactoryBuilder types
recently introduced in 3.1 M2. This is in light of the impending
release of Hibernate 4.0 GA and our own support for it the new
org.springframework.orm.hibernate4 package (not yet committed).
This new package will have a similar, but far simpler, arrangement of
a single LocalSessionFactoryBuilder and LocalSessionFactoryBean pair.
Hibernate 3.x support will remain largely as-is, however the
HibernateTransactionManager introduced with SPR-8076 will remain.
This reverts commit 9e8259198f.
Issue: SPR-8066, SPR-7936, SPR-8076, SPR-8098, SPR-8096, SPR-7387
Removed formal deprecation warnings for AbstractSingletonFactoryBean and
its TransactionProxyFactoryBean and CacheProxyFactoryBean subclasses.
This is principally because TPFB is still used by Grails and could
conceivably be used to good effect by any third-party framework in a
similar fashion. CPFB is new with 3.1, but similar use is predictable.
Deprecations have been replaced by strong recommendations that users
avoid these types in modern Spring applications and favor the use of
namespaces and annotatinos, such as tx: and @Transactional (around
since Spring 2.x) and cache: and @Cacheable.
Issue: SPR-8680, SPR-8686
In anticipation of 'destroy method inference' feature, introduce
ConfigurationClassUtils#INFER_METHOD and update @Bean#destroyMethod to
reflect its use.
Issue: SPR-8751
When a @ModelAttribute is instantiated from a URI variable with type
conversion, if conversion fails allow the exception to propagate.
This is consistent with what happens on type conversion failure with
@PathVariable and other args that rely on type conversion.
Make it possible to hook in custom ServletRequestDataBinderFactory
by overriding RequestMappingHandlerAdapter.
Create ExtendedServletRequestDataBinder to add URI template vars
to the binding values taking advantage of a new extension hook in
ServletRequestDataBinder to provide additional values to bind.
RequestCondition types keep individual expression types (e.g. the
discrete header or param expressions) package private. Although the
implementation of these types should remain private, there is no
reason not to provide access to the underlying expression data --
e.g. for creating a REST endpoint documentation tool, or if you
want to know which of the "consumes"/"produces" media types
are negated.
This change ensures that all RequestCondition types have a public
getter that makes available the basic expression data.
1. Consider single-purpose return value types like HttpEntity, Model,
View, and ModelAndView ahead of annotations like @ResponseBody and
@ModelAttribute. And reversely consider multi-purpose return value
types like Map, String, and void only after annotations like
@RB and @MA.
2. Order custom argument resolvers and return value handlers after the
built-in ones also clarifying the fact they cannot be used to override
the built-in ones in Javadoc throughout.
3. Provide hooks in RequestMappingHandlerAdapter that subclasses can use
to programmatically modify the list of argument resolvers and return
value handlers, also adding new getters so subclasses can get access
to what they need for the override.
4. Make SessionStatus available through ModelAndViewContainer and
provide an argument resolver for it.
5. Init test and javadoc improvements.
Previously, #containsBean Javadoc advertised that a true return value
indicates that a call to #getBean for the same name would succeed.
This is actually not the case, and has never been. The semantics
of #containsBean have always been to indicate whether a bean definition
with the given name is definied or a singleton instance with the given
name has been registered.
The Javadoc now reflects this accurately.
Issue: SPR-8690
Cite original inspiriation by Domain-Driven Design, but make clear the
flexible and general-purpose nature of Spring's stereotype annotations
such as @Repository and @Service.
Also update @Repository Javadoc with more explicit instructions about
switching on exception translation through use of
PersistenceExceptionTranslationPostProcessor, and update PETPP Javadoc
for style as well as concrete examples of 'resource factories' that
implement the PersistenceExceptionTranslator interface
Issue: SPR-8691
When set to 'true' the flag makes RedirectAttributes the only way to add
attributes for a redirect thus ignoring the content of the default model
even if RedirectAttributes is not in the list of controller method args.
Commit http://bit.ly/nXumTs ensured that component methods and fields
marked with 'common annotations' such as @Resource, @PostConstruct and
@PreDestroy are invoked/assigned once and only once, even if multiple
instances of the CommonAnnotationBeanPostProcessor are processing the
same bean factory.
The implementation works against the InjectionMetadata API, adding and
removing these members from sets that track whether they are already
'externally managed', i.e. that another CABPP has already handled them,
thus avoiding redundant processing.
Prior to this change, the #remove operations against these sets were
not synchronized. In a single-threaded context this is fine thanks to
logic in AbstractAutowireCapableBeanFactory#doCreateBean that checks to
see whether a given bean definition has already been post processed.
However, as reported by SPR-8598, certain cases involving multiple
threads and annotated prototype-scoped beans can cause concurrent
modification exceptions during the #remove operation (ostensibly because
another thread is attempting to do the same removal at the same time,
though this has yet to be reproduced in isolation).
Now the sets originally introduced by the commit above are decorated
with Collections#synchronizedSet and any iterations over those sets
are synchronized properly. This change should have low performance
impact as such processing happens at container startup time (save for
non-singleton lookups at runtime), and there should be little
contention in any case.
Issue: SPR-8598
Separate client from server errors as much as possible in this order:
- raise MultipartException when resolving a multipart arg and the
request is not a multipart request (400)
- raise IllegalArgumentException when the arg type is MultipartFile
but the request is not of type MultipartHttpServletRequest (500)
- raise MissingServletRequestPartException when a MultipartResolver
is in use but the part is not found (400)
- detect presence of Servlet 3.0 before using standard multipart
parsing to find a request part or raise
IllegalArgumentException (500)
Unfortunately it is not always possible to separate client from
server errors mainly because the Servlet 3.0 API does not
distinguish between the case of 0 request parts vs multipart
processing not being configured.
Prior to this change, spring-orm/template.mf was exclusive of javax.jdo
3.0.0. Now, after local testing against the newly-released jdo-api 3.0
jar, the template has been updated to allow for use in OSGi containers.
Note that actually updating build dependency descriptors to JDO 3.0 such
that the framework is continually tested against this version is covered
by a separate issue (SPR-8668).
Issue: SPR-8667, SPR-8655
Prior to this change, StandardServletEnvironment evaluated a
"jndiPropertySourceEnabled" flag to determine whether or not to add a
JndiPropertySource. Following the changes introduced in SPR-8490, there
is now no reason not to enable a JNDI property source by default. This
change eliminates the support for "jndiPropertySourceEnabled" and adds
a JndiPropertySource automatically.
Issue: SPR-8545, SPR-8490
Provides a convenient mechanism for activating an additional profile
while preserving those that are already active, as opposed to
calling #setActiveProfiles with the contents of #getActiveProfiles plus
the new profile.
Issue: SPR-8548
- Removed generatesDefaults() and supports() from the SmartContextLoader SPI and modified the DelegatingSmartContextLoader algorithm accordingly.
- DelegatingSmartContextLoader no longer operates on a list of candidate loaders but rather on explicit instances of GenericXmlContextLoader and AnnotationConfigContextLoader.
- Updated Javadoc regarding DelegatingSmartContextLoader as the new default loader.
- Updated and polished Javadoc regarding changes in 3.1.
- Now enforcing @ContextConfiguration's restriction on declaring locations or classes but not both.
SessionFactory proxies created by (Annotation)SessionFactoryBuilder now
implement InfrastructureProxy to ensure they are automatically unwrapped
for transaction resource management purposes.
Issue: SPR-8492
Prior to this change, a parsing exception would be thrown if a
<description> element was placed within a <map><entry/></map>
element. The beans XSD has always permitted this arrangement,
but BeanDefinitionParserDelegate did not respect it. The latter now
simply ignores any <description> element, rather than failing.
Issue: SPR-8563
A <scheduled:task> element declared within a
<beans default-lazy-init="true"> element represents a contradiction in
terms: such a task will never be executed.
For this reason, we now override any inherited lazy-init settings
when parsing <scheduled:task> elements, forcing lazy-init to false
for the underlying ScheduledTaskRegistrar bean.
Thanks to Mike Youngstrom for contributing an initial patch.
Issue: SPR-8498
This change returns the invocation order of
ConfigurationClassPostProcessor#enhanceConfigurationClasses to its
pre-3.1 M2 state. An earlier (and now unnecessary) refactoring in
service of @Feature method processing caused the change that this now
reverts.
Prior to this change, an instance of ConfigurationClassPostProcessor
would throw IllegalStateException if its
postProcessBeanDefinitionRegistry method were called more than once.
This check is important to ensure that @Configuration classes are
not proxied by CGLIB multiple times, and works for most normal use
cases.
However, if the same CCPP instance is used to process multiple
registries/factories/contexts, this check creates a false negative
because it does not distinguish between invocations of
postProcessBeanDefinitionRegistry across different registries.
A use case for this, though admittedly uncommon, would be creating
a CCPP instance and registering it via
ConfigurableApplicationContext#addBeanDefinitionPostProcessor against
several ApplicationContexts. In such a case, the same CCPP instance
will post-process multiple different registry instances, and throw the
above mentioned exception.
With this change, CCPP now performs lightweight tracking of the
registries/beanFactories that it has already processed by recording
the identity hashcodes of these objects. This is only slightly more
complex than the previous boolean-based 'already processed' flags, and
prevents this issue (however rare it may be) from occurring.
Issue: SPR-8527
<emphasis role="bold"> blocks do not render properly, probably due to
conflicting CSS used for syntax highlighting. For the moment, any
mentions of bold text (e.g. "see bold text in the snippet below") have
been removed to avoid confusion as reported in SPR-8520. SPR-8526 has
been created to address the underlying issue of getting bold to work
even with syntax highlighting.
Issue: SPR-8520, SPR-8526
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
@PostConstruct added to ProxyTransactionManagementConfiguration cases
ConcurrentModificationException (as detailed previously in SPR-8397.
Backing out for now until a better solution can be devised.
This reverts commit 235b729514.
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.
Rather than trying to rework how AopConfigUtils works, a @PostConstruct
method has been added to ProxyTransactionManagementConfiguration to call
the usual AopConfigUtils registration methods.
Issue: SPR-8411, SPR-8494
SessionFactoryBuilderSupport implementations create DisposableBean
proxies for SessionFactory objects created using #buildSessionFactory.
Prior to this change, these proxies create problems when working agaist
SessionFactoryUtils.getDataSource(SessionFactory), because this method
expects the given SessionFactory to implement Hibernate's
SessionFactoryImplementor interface (which the stock SessionFactoryImpl
does).
With this change, the DisposableBean proxies created by SFBuilders
now also implement SessionFactoryImplementor to satisfy this and
probably other such cases.
Issue: SPR-8469
For the particular use case detailed in SPR-8514, with this change we
now attempt to determine the object type of a FactoryBean through its
generic type parameter if possible.
For (a contrived) example:
@Configuration
public MyConfig {
@Bean
public FactoryBean<String> fb() {
return new StringFactoryBean("foo");
}
}
The implementation will now look at the <String> generic parameter
instead of attempting to instantiate the FactoryBean in order to call
its #getObjectType() method.
This is important in order to avoid the autowiring lifecycle issues
detailed in SPR-8514. For example, prior to this change, the following
code would fail:
@Configuration
public MyConfig {
@Autowired Foo foo;
@Bean
public FactoryBean<String> fb() {
Assert.notNull(foo);
return new StringFactoryBean("foo");
}
}
The reason for this failure is that in order to perform autowiring,
the container must first determine the object type of all configured
FactoryBeans. Clearly a chicken-and-egg issue, now fixed by this
change.
And lest this be thought of as an obscure bug, keep in mind the use case
of our own JPA support: in order to configure and return a
LocalContainerEntityManagerFactoryBean from a @Bean method, one will
need access to a DataSource, etc -- resources that are likely to
be @Autowired across @Configuration classes for modularity purposes.
Note that while the examples above feature methods with return
types dealing directly with the FactoryBean interface, of course
the implementation deals with subclasses/subinterfaces of FactoryBean
equally as well. See ConfigurationWithFactoryBeanAndAutowiringTests
for complete examples.
There is at least a slight risk here, in that the signature of a
FactoryBean-returing @Bean method may advertise a generic type for the
FactoryBean less specific than the actual object returned (or than
advertised by #getObjectType for that matter). This could mean that an
autowiring target may be missed, that we end up with a kind of
autowiring 'false negative' where FactoryBeans are concerned. This is
probably a less common scenario than the need to work with an autowired
field within a FactoryBean-returning @Bean method, and also has a clear
workaround of making the generic return type more specific.
Issue: SPR-8514
isCglibProxy* methods in AopUtils are useful in lower-level modules,
i.e. those that cannot depend on .aop. Therefore copied these methods
to ClassUtils; deprecated the existing ones in AopUtils and now
delegating to the new location; switched all usage of
AopUtils#isCglibProxy* within the framework to use
ClassUtils#isCglibProxy* instead.
Even after applying @Ignore to these tests at the class level, they
still run (and fail) under ant when the jmxremote_optional jar is not
present. See the issues mentioned below for information on how these
tests will be re-enabled.
Issue: SPR-8089, SPR-8093, SPR-8458
Prior to this change, (Context)SingletonBeanFactoryLocator used
BeanFactoryUtils#beanOfType(ListableBeanFactory, Class) to locate the
bean of type BeanFactory.
The more modern approach is to use BeanFactory#getBean(Class), which
removes a dependency on ListableBeanFactory interface while at the same
time opening the implementation up to respecting autowiring exclusions,
primary metadata, etc.
Issue: SPR-8489
For consistency with all other constants representing default
property source names, such as
StandardServletEnvironment#SERVLET_CONTEXT_PROPERTY_SOURCE_NAME and
StandardEnvironment#SYSTEM_ENVIRONMENT_PROPERTY_SOURCE_NAME
Issue: SPR-8482
Prior to this change, JndiPropertySource worked directly against a JNDI
Context instance as its 'source' object. This works well enough, but is
not nearly as fully-featured as Spring's existing JndiLocatorDelegate.
This change refactors JndiPropertySource from relying on an underlying
Context to relying on an underlying JndiLocatorDelegate. By default,
the delegate's "resourceRef" property is set to true, meaning that the
implementation will always try to prepand a given name with
"java:comp/env/" before looking up the name, and upon failure will drop
back to the given name sans prefix.
See JndiPropertySource Javadoc for complete details.
Issue: SPR-8490
Move JNDI_PROPERTY_SOURCE_ENABLED_FLAG from JndiPropertySource to
StandardServletEnvironment, as this is the only context in which the
constant makes sense.
Users may now work with command line arguments as a source of
properties for use with the PropertySource and Environment APIs.
An implementation based on the jopt library and a "simple"
implementation requiring no external libraries are are provided
out-of-the box.
See Javadoc for CommandLinePropertySource, JOptCommandLinePropertySource
and SimpleCommandLinePropertySource for details.
Issue: SPR-8482
Prior to this change, @Autowired injection against an instance of a
subclass having different visibility than its superclass would fail
if the @Autowired method is declared only in the superclass. This is due
to an apparent change in the rules around bridge method generation
between Java 5 and Java 6, and possibly even varying across compiler
vendors.
Now, BridgeMethodResolver is used consistently when detecting
@Autowired, @Inject and @Resource metadata to bypass these bridge
methods if they exist.
Issue: SPR-7900
- introduced processContextConfigurationAttributes() method in SmartContextLoader SPI
- refactored AnnotationConfigContextLoader, AbstractContextLoader, AbstractGenericContextLoader, ContextLoaderUtils, and TestContext implementations to take advantage of the SmartContextLoader SPI, MergedContextConfiguration, and ContextConfigurationAttributes
- deleted ResourceTypeAwareContextLoader
- deleted ContextLoaderUtils.LocationsResolver and implementations
- moved context key generation from TestContext to MergedContextConfiguration
Prior to this change, AbstractAutowireCapableBeanFactory did not support
a default ParameterNameDiscoverer. This meant that attempting to use
<constructor-arg name=".."> syntax would fail (with a fairly obscure
exception) as that feature depends on a ParameterNameDiscoverer to
introspect the constructor arguments.
This lack of a default was originally intended to avoid a dependency on
ASM, but now that (a) .asm is a built-in module and (b) .beans has a
non-optional compile-time dependency on .asm, there is no reason not to
provide this default.
The net effect is that in a number of locations throughout the
framework, namely in GenericApplicationContext and
AbstractRefreshableApplicationContext, it is no longer necessary to
explicitly call AACBF#setParameterNameDiscoverer. This also means that
using a naked BeanFactory (likely for testing scenarios) is that much
easier.
Issue: SPR-8184
Prior to this change, the Property class introduced in 3.1 M2 validated
read/write property method pairs based on whether their parameter/return
types were equal to one another. This precluded the valid possibility
of read method that returns a subtype of the write method's parameter
type, and represented a regression against 3.1 M1 and earlier versions.
The implementation now uses isAssignableFrom rather than a straight
equals check against the types.
Issue: SPR-8432
As of SPR-8093, jmxremote_optional.jar is present on the build
server in jre/lib/ext, but it is not by default present on local
developer / user machines, meaning that the build ends up broken
by default.
Issue: SPR-8089, SPR-8093, SPR-8458
Prior to this change, DirectFieldAccessor would ignore fields shadowed
in subclasses, favoring the last field processed, which happens to be
the most super declaration based on the way ReflectionUtils.doWithFields
works.
Because the locally shadowed field may be of a different type that the
superclass declaration, it is most correct to preserve and work with
the shadowed field.
Issue: SPR-8398
- TextContext now works with MergedContextConfiguration instead of locations and loader
- TextContext now builds context caching key from MergedContextConfiguration
- Test context caching is now based on locations, classes, active profiles, and context loader
- TextContext now delegates to SmartContextLoader or ContextLoader as appropriate
- AbstractContextLoader now implements SmartContextLoader
- AbstractGenericContextLoader now sets active profiles in the GenericApplicationContext
- Introduced integration tests for profile support in the TCF for both XML and annotation config
Renamed TransactionManagementConfigurer#createTransactionManager()
to #annotationDrivenTransactionManager() to better reflect the fact
that the implemented method is optionally eligible for @Bean annotation.
See Javadoc for details.
+ remove generic signature on key generator (as the type is not used anywhere)
+ add a small improvement to CacheAspect to nicely handle the cases where the aspect is pulled in but not configured
Consolidates ConversionService and ConverterRegistry interfaces;
implemented by GenericConversionService.
ConfigurablePropertyResolver#getConversionService now returns this
new type (hence so too does
ConfigurableEnvironment#getConversionService). This allows for
convenient addition / removal of Converter instances from Environment's
existing ConversionService. For example:
ConfigurableApplicationContext ctx = new ...
ConfigurableEnvironment env = ctx.getEnvironment();
env.getConversionService().addConverter(new FooConverter());
Issue: SPR-8389
This reverts commit da914bcfb4 and also
removes the use of Ordered#NOT_ORDERED from EnableTransactionManagement
and ProxyTransactionManagementConfiguration in favor of defaulting to
Ordered#LOWEST_PRIORITY, which is actually the default that results
when no 'order' attribute is specified in XML.
Attempt to access and modify the system environment works on OS X /
Linux but not under Windows. Does not represent any real failure for
production code - the need to modify the system environment is a
testing concern only, and one we can probably live without, considering
the losing battle necessary to make such a hack cross-platform.
Issue: SPR-8245
Constructors have been added to both ContextLoader and
ContextLoaderListener to support instance-based programmatic
registration of listeners within ServletContainerInitializer
implementations in Servlet 3.0+ environments, and more particularly
when using Spring 3.1's WebApplicationInitializer SPI.
Issue: SPR-7672
ContextLoader and FrameworkServlet now use
AnnotationAwareOrderComparator to support @Order usage; previously
supported only implementation of the Ordered interface.
Constructors have been added to both FrameworkServlet and
DispatcherServlet to support instance-based programmatic registration
of Servlets within ServletContainerInitializer implementations in
Servlet 3.0+ environments, and more particularly when using Spring 3.1's
WebApplicationInitializer SPI.
This change also renames the method added to FrameworkServlet in
SPR-8185 from #initializeWebApplicationContext to #applyInitializers.
The reason being that a method named #initWebApplicationContext was
already present and the names overlapped confusingly.
Issue: SPR-7672, SPR-8185
GenericWebApplicationContext now implements
ConfigurableWebApplicationContext in order to be compatible with
Framework/DispatcherServlet and ContextLoader/Listener, especially with
regard to changes in SPR-7672 that allow for programmatic use of these
types within Servlet 3.0+ environments. For the first time, it's now
reasonable to imagine injecting a GWAC into DispatcherServlet; the most
robust way to accommodate this possibility is for GWAC to implement
CWAC.
The implementation is in name only, allowing for interchangable use of
GWAC anywhere, for example, an XWAC could otherwise go. Methods such
as setConfigLocation will throw UnsupportedOperationException if the
configLocation value actually contains text. Other methods are
implemented as no-ops or to throw UOE as appropriate.
Issue: SPR-7672
WebApplicationInitializer provides a programmatic alternative to the
traditional WEB-INF/web.xml servlet container deployment descriptor
for Servlet API 3.0+ environments.
This is done by building atop the new ServletContainerInitializer
support in Servlet 3.0. See SpringServletContainerInitializer for
complete details. And see WebApplicationInitializer Javadoc for
typical usage examples.
Issue: SPR-7672
In support of SPR-7672 which will support code-based configuration
alternatives to web.xml using new features in the Servlet 3.0 API.
This upgrade does *not* force Spring users to upgrade to Servlet 3.0
capable containers. Compatibility with and support for
javax.servlet >= 2.4 remains.
Issue: SPR-7672
Calls to AbstractApplicationContext#setParent delegate the parent
context environment to the child.
This ensures that any property sources added to the parent are available
to the child as well as ensuring that any profiles activated are
activated everywhere.
Child contexts may still choose to replace their environment (through an
ApplicationContextInitializer, for example). In any case, however, in
the root/child web application context relationship established by
ContextLoader + DispatcherServlet, the child is guaranteed to have
already been given the parent environment by the time it is delegated
to any ACIs.
See AbstractApplicationContext#setParent for implementation
See FrameworkServlet#createWebApplicationContext for order in which
setParent then initializeWebApplicationContext are called.
Issue: SPR-8185
AnnotationConfigApplicationContext and
AnnotationConfigWebApplicationContext both expose #register and #scan
methods as of the completion of SPR-8320. This change introduces a new
interface that declares each of these methods and refactors ACAC and
ACWAC to implement it.
Beyond information value, this is useful for implementors of the
ApplicationContextInitializer interface, in that users may create an ACI
that works consistently across ACAC and ACWAC for standalone (e.g.
testing, batch) or web (e.g. production) use.
Issue: SPR-8365,SPR-8320
Primarily for use in conjunction with ApplicationContextInitializer,
these new #scan and #register methods mirror those in
AnnotationConfigApplicationContext. #setConfigLocation
and #setConfigLocations methods remain for compatibility with
ContextLoader-style initialization, but have been locally overridden
and documented clearly.
AnnotationConfigWebApplicationContext#loadBeanDefinitions Javadoc has
also been updated to explain the processing logic for each of these
potential inputs.
Issue: SPR-8320
FrameworkServlet now has support equivalent to ContextLoader and its
"contextInitializerClasses" context-param introduced in 3.1 M1.
This allows users to specify ApplicationContextInitializers at the root
(ContextLoader) level and/or at the DispatcherServlet level.
Issue: SPR-8366
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
ClassMetadata implementations can now introspect their member (nested)
classes. This will allow for automatic detection of nested
@Configuration types in SPR-8186.
Issue: SPR-8358,SPR-8186
This new hook in the AbstractEnvironment lifecycle allows for more
explicit and predictable customization of property sources by
subclasses. See Javadoc and existing implementations for detail.
Issue: SPR-8354
AbstractEnvironment and subclasses now register a reserved default
profile named literally 'default' such that with no action on the part
of the user, beans defined against the 'default' profile will be
registered - if no other profiles are explicitly activated.
For example, given the following three files a.xml, b.xml and c.xml:
a.xml
-----
<beans> <!-- no 'profile' attribute -->
<bean id="a" class="com.acme.A"/>
</beans>
b.xml
-----
<beans profile="default">
<bean id="b" class="com.acme.B"/>
</beans>
c.xml
-----
<beans profile="custom">
<bean id="c" class="com.acme.C"/>
</beans>
bootstrapping all of the files in a Spring ApplicationContext as
follows will result in beans 'a' and 'b', but not 'c' being registered:
ApplicationContext ctx = new GenericXmlApplicationContext();
ctx.load("a.xml");
ctx.load("b.xml");
ctx.load("c.xml");
ctx.refresh();
ctx.containsBean("a"); // true
ctx.containsBean("b"); // true
ctx.containsBean("c"); // false
whereas activating the 'custom' profile will result in beans 'a' and
'c', but not 'b' being registered:
ApplicationContext ctx = new GenericXmlApplicationContext();
ctx.load("a.xml");
ctx.load("b.xml");
ctx.load("c.xml");
ctx.getEnvironment().setActiveProfiles("custom");
ctx.refresh();
ctx.containsBean("a"); // true
ctx.containsBean("b"); // false
ctx.containsBean("c"); // true
that is, once the 'custom' profile is activated, beans defined against
the the reserved default profile are no longer registered. Beans not
defined against any profile ('a') are always registered regardless of
which profiles are active, and of course beans registered
against specific active profiles ('c') are registered.
The reserved default profile is, in practice, just another 'default
profile', as might be added through calling env.setDefaultProfiles() or
via the 'spring.profiles.default' property. The only difference is that
the reserved default is added automatically by AbstractEnvironment
implementations. As such, any call to setDefaultProfiles() or value set
for the 'spring.profiles.default' will override the reserved default
profile. If a user wishes to add their own default profile while
keeping the reserved default profile as well, it will need to be
explicitly redeclared, e.g.:
env.addDefaultProfiles("my-default-profile", "default")
The reserved default profile(s) are determined by the value returned
from AbstractEnvironment#getReservedDefaultProfiles(). This protected
method may be overridden by subclasses in order to customize the
set of reserved default profiles.
Issue: SPR-8203
- removed generics from Cache/CacheManager (they add no value since it's an SPI not API)
+ update docs and tests
+ renamed ConcurrentCacheFactoryBean to ConcurrentMapCacheFactoryBean
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
@Autowired, @Value and other annotations cannot be applied within
Spring Bean(Factory)PostProcessor types, because they themselves
are processed using BeanPostProcessors. Javadoc and reference docs
have been updated to reflect.
Issue: SPR-4935, SPR-8213
A subtle issue existed with the way we relied on isCurrentlyInCreation
to determine whether a @Bean method is being called by the container
or by user code. This worked in most cases, but in the particular
scenario laid out by SPR-8080, this approach was no longer sufficient.
This change introduces a ThreadLocal that contains the factory method
currently being invoked by the container, such that enhanced @Bean
methods can check against it to see if they are being called by the
container or not. If so, that is the cue that the user-defined @Bean
method implementation should be invoked in order to actually create
the bean for the first time. If not, then the cached instance of
the already-created bean should be looked up and returned.
See ConfigurationClassPostConstructAndAutowiringTests for
reproduction cases and more detail.
Issue: SPR-8080
If the enclosing environment does not implement ConfigurableEnvironment,
then @PropertySource annotations are ignored because there is no way to
add them to the Environment. Now checking first to see if there are any
@PropertySource annotations present before issuing the warning.
Issue: SPR-8314
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
Allows convenient creation of a Properties-based PropertySource from a
Spring Resource object or resource location string such as
"classpath:com/myco/app.properties" or "file:/path/to/file.properties"
Issue: SPR-8328
Users may now call #setRequiredProperties(String...) against the
Environment (via its ConfigurablePropertyResolver interface) in order
to indicate which properties must be present.
Environment#validateRequiredProperties() is invoked by
AbstractApplicationContext during the refresh() lifecycle to perform
the actual check and a MissingRequiredPropertiesException is thrown
if the precondition is not satisfied.
Issue: SPR-8323
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
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
Introduce @EnableAsync#order
AsyncAnnotationBeanPostProcessor's 'order' property is now mutable;
@EnableAsync's 'order()' attribute allows for setting it, but must
have a default value, thus uses the new Ordered#NOT_ORDERED
constant - a reserved negative number very unlikely to be otherwise
used that may be interpreted as 'not ordered', useful in annotation
defaulting scenarios where null is not an option.
Introduce first working cut of AsyncConfiguration
Remove AsyncCapability
This change is in support of certain polymorphism cases in
@Configuration class inheritance hierarchies. Consider the following
scenario:
@Configuration
public abstract class AbstractConfig {
public abstract Object bean();
}
@Configuration
public class ConcreteConfig {
@Override
@Bean
public BeanPostProcessor bean() { ... }
}
ConcreteConfig overrides AbstractConfig's #bean() method with a
covariant return type, in this case returning an object of type
BeanPostProcessor. It is critically important that the container
is able to detect the return type of ConcreteConfig#bean() in order
to instantiate the BPP at the right point in the lifecycle.
Prior to this change, the container could not do this.
AbstractAutowireCapableBeanFactory#getTypeForFactoryMethod called
ReflectionUtils#getAllDeclaredMethods, which returned Method objects
for both the Object and BeanPostProcessor signatures of the #bean()
method. This confused the implementation sufficiently as not to
choose a type for the factory method at all. This means that the
BPP never gets detected as a BPP.
The new method being introduced here, #getUniqueDeclaredMethods, takes
covariant return types into account, and filters out duplicates,
favoring the most specific / narrow return type.
Additionally, it filters out any CGLIB 'rewritten' methods, which
is important in the case of @Configuration classes, which are
enhanced by CGLIB. See the implementation for further details.
Consolidating internal bean name and aspect class name constats within
AnnotationConfigUtils to allow access from both the context.config
and context.annotation packages without creating a relationship between
the two of them (they are unrelated leaf nodes in the packaging
currently).
The .transaction module does not have a similar utils class and already
has a relationship from transaction.config -> transaction.annotation,
so placing the constants in .annotation.TransactionManagementCapability
to be referenced by .config.AnnotationDrivenBeanDefinitionParser
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.
Feature-related support such as @Feature, @FeatureConfiguration,
and FeatureSpecification types will be replaced by framework-provided
@Configuration classes and convenience annotations such as
@ComponentScan (already exists), @EnableAsync, @EnableScheduling,
@EnableTransactionManagement and others.
Issue: SPR-8012,SPR-8034,SPR-8039,SPR-8188,SPR-8206,SPR-8223,
SPR-8225,SPR-8226,SPR-8227
The overloading necessary to preserve the new signature as well as
the old causes ambiguities leading to deprecation warnings in some
caller scenarios.
- Removed AbstractGenericContextLoader's createGenericApplicationContext() method.
- AnnotationConfigContextLoader now uses an AnnotatedBeanDefinitionReader instead of working with an AnnotationConfigApplicationContext.
- AnnotationConfigContextLoader now uses the supplied GenericApplicationContext to load configuration classes.
SessionFactory objects created by
SessionFactoryBuilderSupport#buildSessionFactory are now DisposableBean
proxies that call SessionFactory#close and release any threadlocal
DataSource object.
This is the same behavior that has always occurred during LSFBean and
ASFBean destruction lifecycles (and still does). This destruction logic
has now been factored out into
SessionFactoryBuilderSupport#closeHibernateSessionFactory such that all
SFB types can reuse it easily.
Note that LSFBean and ASFBean are subclasses, respectively, of SFBuilder
and ASFBuilder and they each must disable the DisposableBean proxying in
order to avoid duplicate attempts at closing the SessionFactory. See
the implementations of wrapSessionFactoryIfNeccesary() for details.
Issue: SPR-8114
Previously, ExtendedBeanInfo would attempt to process methods named
exactly 'set'. JavaBeans properties must have at least one character
following the 'set' prefix in order to qualify, and this is now
respected by EBI.
Thanks to Rob Winch for the patch fixing this problem.
Issue: SPR-8175
Large refactoring of existing *SessionFactoryBean hierarchy designed to
support configuration of Hibernate SessionFactory objects within
@Configuration class @Bean methods without forcing use of a
FactoryBean type, which is generally discouraged due to awkwardness
of programming model and lifecycle issues. Refactored and new types
include:
* Removal of AbstractSessionFactoryBean, replacing it with
SessionFactoryBeanSupport abstract base class
* Introduction of SessionFactoryBuilder and
AnnotationSessionFactoryBuilder types, both direct subclasses of
SessionFactoryBuilderSupport. These types are intended for direct
use within @Bean methods. They expose method-chainable set*
methods allowing for concise and convenient use. See JavaDoc
on both types for usage examples.
* LocalSessionFactoryBean and AnnotationSessionFactoryBean types are
now subclasses, respectively, of the *Builder types above.
LSFB and ASFB backward-compatibility has been maintained almost
entirely. The one exception is that there is no longer a protected
convertHibernateAccessException() method available in the hierarchy.
This method was not likely often used anyway and has been replaced
by the new (and public) setPersistenceExceptionTranslator() which
accepts instances of type HibernateExceptionTranslator as introduced in
SPR-8076.
LSFB and ASFB setter method signatures have changed. They no longer
return void in standard JavaBeans style but rather, and due to extending
the *Builder types above, return the 'this' reference. This posed a
problem because the Spring container has to date been unable to detect
and provide dependency injection against non-void returning setter
methods. This limitation was due to the way that the default JavaBeans
Introspector class and its getBeanInfo() method works, and prompted the
introduction and intergration of ExtendedBeanInfo, already completed in
SPR-8079. So have no concern if you notice this signature change - it
all works.
Certain deprecations have been made:
* All LSFB/ASFB methods related to Hibernate's CacheProvider SPI,
reflecting its deprecation in Hibernate 3.3 in favor of the new
RegionFactory SPI. Note these methods have been preserved only
on the FactoryBean types. The new *SessionFactoryBuilder
supertypes do not expose CacheProvider services at all.
* All protected LSFB/ASFB methods that accept a Hibernate
Configuration parameter, such as newSessionFactory(Configuration),
postProcessMappings(Configuration) and
postProcessConfiguration(Configuation), in favor of no-arg methods
with the same names. Due to the nature of the hierarchy
refactoring mentioned above, the Configuration instance is always
available when these methods are called, thus no need to pass it
in as a parameter.
In the process, our approach to automatic detection of Hibernate dialect
has been improved (it was in fact broken before). Thanks to James
Roper for his suggestion in SPR-7936 as to how to fix this.
See HibernateSessionFactoryConfigurationTests as a starting point for
understanding the new builder-style approach to SessionFactory creation.
Note especially use of the SessionFactoryBuilder#doWithConfiguration
method which allows for direct programmatic configuration of the Native
Hibernate (Annotation)Configuration API.
As a final note, AnnotationConfiguration has been deprecated in
Hibernate 3.6, and great pains have been taken to ensure that users
of any supported Hibernate version (3.2 -> 3.6) will never need to
(a) cast from Configuration to AnnotationConfiguration or (b)
experience deprecation warnings due to being forced to use the
AnnotationConfiguration API. Explore the JavaDoc around the
doWithConfiguration() method and HibernateConfigurationCallback type
for complete details.
Issue: SPR-8066, SPR-7936, SPR-8076, SPR-8098
Designed to allow persistence exception translation of
HibernateException types without being forced to use
LocalSessionFactoryBean types.
Committed now in support of the forthcoming introduction of
*SessionFactoryBuilder types.
Issue: SPR-8076
Decorator for instances returned from
Introspector#getBeanInfo(Class<?>) that supports detection and inclusion
of non-void returning setter methods. Fully supports indexed properties
and otherwise faithfully mimics the default
BeanInfo#getPropertyDescriptors() behavior, e.g., PropertyDescriptor
ordering, etc.
This decorator has been integrated with CachedIntrospectionResults
meaning that, in simple terms, the Spring container now supports
injection of setter methods having any return type.
Issue: SPR-8079
Previously errors were being raised when trying to inject @Value
annotated paramaters such as:
@Feature
public FeatureSpec feature(@Value("#{environment['foo']}") String foo) {
return new FeatureSpec(foo);
}
This is not so much because dependency resolution of @Value-annotated
types was failing, but rather because the 'early bean reference'
proxying mechanism was throwing an exception if any final type was
detected as a parameter. This is of course because final types are
non-subclassable by CGLIB. On review, however, it's obvious that
certain final types must be allowed for injection. @Value injection
is an obvious one, but the rarer case of a Spring bean of type String
or int is another.
The explicit guard against final types as parameters to @Feature methods
has been removed. Final types are still checked for, however, and if
found, no proxing is attempted. The dependency is immediately resolved
against the current BeanFactory and injected into the @Feature method.
This means that @Value injection, @Qualifier injection, etc all work
as expected, but does mean that premature bean instantiation may occur
if a user unwittingly injects non-String, non-primitive final bean types
as @Feature method parameters.
Issue: SPR-7974
CGLIB-enhanced @Configuration subclasses now implement DisposableBean
such that Enhancer.registerStaticCallbacks(subclass, null) is invoked
on container shutdown. This ensures that garbage collection can work
properly and avoids memory consumption issues for applications that
create and destroy many application contexts within the same JVM.
Issue: SPR-7901
context:property-placeholder extends 'propertyPlaceholder' type
defintion once again. This relationship was inadvertently removed in
3.1 M1, and the effect was that XML tooling would raise errors on
use of attributes like 'location'.
The updated schema has also been published to
http://www.springframework.org/schema/context/spring-context-3.1.xsd
Issue: SPR-8037
Prove that injection of special container types such as ResourceLoader,
BeanFactory, etc already works with the current implementation of
@Feature methods.
Issue: SPR-7975
Previously, only commas could delimit <beans profile="p1,p2"/>. Now, as
with <bean alias="..."/>, the profile attribute allows for delimiting
by comma, space and/or semicolon.
BeanDefinitionParserDelegate.MULTI_VALUE_ATTRIBUTE_DELIMITERS has been
added as a constant to reflect the fact this set of delimiters is used
in multiple locations throughout the framework.
BDPD.BEAN_NAME_DELIMITERS now refers to the above and has been has been
preserved but deprecated for backward compat (though use outside the
framework is unlikely).
Changes originally based on user comment at
http://blog.springsource.com/2011/02/11/spring-framework-3-1-m1-released/comment-page-1/#comment-184455
Issue: SPR-8033
Current STS version of Spring (3.0.5) does not contain
the BeanUtils.instantiateClass(Class<?>, Class<T>) signature
that was added in 3.1.0, therefore NoSuchMethodErrors are
being thrown when STS classloads and delegates to
3.1.0 NamespaceHandler and BeanDefinitionParser implementations
on the user project classpath.
In this case, it's AbstractSpecificationBeanDefinitionParser
doing the calling to the unknown new method. In this specific
example, reverting back to the old single-arg signature is actually
not a problem, because it does accept Class<T> and returns an
instance of type T, which was the desired behavior in the first
place.
The newer signature remains in order to accommodate callers
who do not know the generic type of the Class to be instantiated
(i.e. Class<?>), but do know the type that it should be assignable
to -- this becomes the second argument Class<T>, and an instance
of type T is returned (if indeed it is assignable to the specified
type; otherwise IllegalArgumentException.
Defensively catch NoSuchMethodError when calling BDPD.getEnvironment()
and supply a DefaultEnvironment if not available.
Replace the single-arg constructor for BDPD and deprecate, preserving
binary compat particularly for Spring Integration who instantiates
this class directly, which is unusual.
Revert changes to ParserContext, ReaderContext, and XmlReaderContext
These changes cause cross-version incompatibilities at tooling time
-- for instance, an STS version that ships with Spring 3.0.5
classloads the ParserContext defined in that version, whereas it
classloads NamespaceHandlers and BeanDefinitionParsers (by default)
from the user application classpath, which may be building against
3.1.0. If so, the changes introduced to these types in 3.1.0 are
incompatible with expectations in the 3.0.5 world and cause all
manner of problems. In this case, it was NoSuchMethodError due to
the newly-added XmlReaderContext.getProblemReporter() method; also
IncompatibleClassChangeError due to the introduction of the
ComponentRegistrar interface on ParserContext.
Each of these problems have been mitigated, though the solutions
are not ideal. The method mentioned has been removed, and instead
the problemReporter field is now accessed reflectively.
ParserContext now no longer implements ComponentRegistrar, and
rather a ComponentRegistrarAdapter class has been introduced that
passes method calls through to a ParserContext delegate.
Introduce AbstractSpecificationBeanDefinitionParser
AbstractSpecificationBeanDefinitionParser has been introduced in
order to improve the programming model for BeanDefinitionParsers
that have been refactored to the new FeatureSpecification model.
This new base class and it's template method implementation of
parse/doParse ensure that common concerns like (1) adapting a
ParserContext into a SpecificationContext, (2) setting source and
source name on the specification, and (3) actually executing the
specification are all managed by the base class. The subclass
implementation of doParse need only actually parse XML, populate
and return the FeatureSpecification object. This change removed
the many duplicate 'createSpecificationContext' methods that had
been lingering.
Minor improvement to BeanDefinitionReaderUtils API
Introduced new BeanDefinitionReaderUtils#registerWithGeneratedName
variant that accepts BeanDefinition as opposed to
AbstractBeanDefinition, as BeanDefinition is all that is actually
necessary to satisfy the needs of the method implementation. The
latter variant accepting AbstractBeanDefinition has been deprecated
but remains intact and delegates to the new variant in order to
maintain binary compatibility.
This change broke binary compatibility as evidenced by running
the greenhouse test suite and finding that Spring Integration's
AbstractConsumerEndpointParser.parseInternal fails with
NoSuchMethodError when trying to invoke.
Introduce FeatureSpecification interface and implementations
FeatureSpecification objects decouple the configuration of
spring container features from the concern of parsing XML
namespaces, allowing for reuse in code-based configuration
(see @Feature* annotations below).
* ComponentScanSpec
* TxAnnotationDriven
* MvcAnnotationDriven
* MvcDefaultServletHandler
* MvcResources
* MvcViewControllers
Refactor associated BeanDefinitionParsers to delegate to new impls above
The following BeanDefinitionParser implementations now deal only
with the concern of XML parsing. Validation is handled by their
corresponding FeatureSpecification object. Bean definition creation
and registration is handled by their corresponding
FeatureSpecificationExecutor type.
* ComponentScanBeanDefinitionParser
* AnnotationDrivenBeanDefinitionParser (tx)
* AnnotationDrivenBeanDefinitionParser (mvc)
* DefaultServletHandlerBeanDefinitionParser
* ResourcesBeanDefinitionParser
* ViewControllerBeanDefinitionParser
Update AopNamespaceUtils to decouple from XML (DOM API)
Methods necessary for executing TxAnnotationDriven specification
(and eventually, the AspectJAutoProxy specification) have been
added that accept boolean arguments for whether to proxy
target classes and whether to expose the proxy via threadlocal.
Methods that accepted and introspected DOM Element objects still
exist but have been deprecated.
Introduce @FeatureConfiguration classes and @Feature methods
Allow for creation and configuration of FeatureSpecification objects
at the user level. A companion for @Configuration classes allowing
for completely code-driven configuration of the Spring container.
See changes in ConfigurationClassPostProcessor for implementation
details.
See Feature*Tests for usage examples.
FeatureTestSuite in .integration-tests is a JUnit test suite designed
to aggregate all BDP and Feature* related tests for a convenient way
to confirm that Feature-related changes don't break anything.
Uncomment this test and execute from Eclipse / IDEA. Due to classpath
issues, this cannot be compiled by Ant/Ivy at the command line.
Introduce @FeatureAnnotation meta-annotation and @ComponentScan impl
@FeatureAnnotation provides an alternate mechanism for creating
and executing FeatureSpecification objects. See @ComponentScan
and its corresponding ComponentScanAnnotationParser implementation
for details. See ComponentScanAnnotationIntegrationTests for usage
examples
Introduce Default[Formatting]ConversionService implementations
Allows for convenient instantiation of ConversionService objects
containing defaults appropriate for most environments. Replaces
similar support originally in ConversionServiceFactory (which is now
deprecated). This change was justified by the need to avoid use
of FactoryBeans in @Configuration classes (such as
FormattingConversionServiceFactoryBean). It is strongly preferred
that users simply instantiate and configure the objects that underlie
our FactoryBeans. In the case of the ConversionService types, the
easiest way to do this is to create Default* subtypes. This also
follows convention with the rest of the framework.
Minor updates to util classes
All in service of changes above. See diffs for self-explanatory
details.
* BeanUtils
* ObjectUtils
* ReflectionUtils
Designed primarily for use in conjunction with web applications
to provide a convenient mechanism for configuring the container
programmatically.
ApplicationContextInitializer implementations are specified through the
new "contextInitializerClasses" servlet context parameter, then detected
and invoked by ContextLoader in its customizeContext() method.
In any case, the semantics of ApplicationContextInitializer's
initialize(ConfigurableApplicationContext) method require that
invocation occur *prior* to refreshing the application context.
ACI implementations may also implement Ordered/PriorityOrdered and
ContextLoader will sort instances appropriately prior to invocation.
Specifically, this new support provides a straightforward way to
programmatically access the container's Environment for the purpose
of adding, removing or otherwise manipulating PropertySource objects.
See Javadoc for further details.
Also note that ApplicationContextInitializer semantics overlap to
some degree with Servlet 3.0's notion of ServletContainerInitializer
classes. As Spring 3.1 development progresses, we'll likely see
these two come together and further influence one another.
DefaultWebEnvironment automatically adds a JndiPropertySource if
a "jndiPropertySourceEnabled" property is detected in any of the
other other default property sources.
* PropertySources is now an Iterable<PropertySource> in favor of
exposing an asList() method
* Otherwise reduced the set of methods exposed by PropertySources to the
absolute minimum
* Added Javadoc for both types and all methods
PropertySourcesPlaceholderConfigurer accommodates recent changes in
Environment and PropertySource APIs, e.g. no longer assuming enumerability
of property names.
PSPC reuses as much functionality as possible from
AbstractPropertyPlaceholderConfigurer, but overrides
postProcessBeanFactory() and defines its own variation on
processProperties() in order to accept a PropertyResolver rather than
a PropertySource.
AbstractPropertyPlaceholderConfigurer introduces doProcessProperties()
method to encapsulate that which is actually common, such as the
visiting of each bean definition once a StringValueResolver has been
created in the subclass.
* 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
All existing *Aware interfaces have been refactored to extend this
new marker interface, serving two purposes:
* Easy access to a type hierarchy that can answer the question
"What *Aware interfaces are available?", without requiring
text-based searches. Also clearly excludes false positives like
TargetClassAware and ParamAware, which while similarly named,
are not semantically similar to traditional *Aware interfaces
in Spring.
* Minor potential performance improvements in
AbstractAutowireCapableBeanFactory and
ApplicationContextAwareProcessor. Both have blocks of sequential
instanceof checks in order to invoke any *Aware interface callback
methods. For a bean that implements none of these interfaces,
the whole sequence can be avoided by guarding first with
if (bean instanceof Aware) {
...
}
Implementors of custom *Aware-style interfaces (and presumably
the BeanPostProcessors that handle them), are encouraged to refactor to
extending this interface for consistency with the framework as well as
the points above.
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.
Changed the documentation to correctly state that B(F)PP are instantiated eagerly no matter if they are explicitly marked as to be lazy initialized or the default-lazy-init attribute is used at a <beans /> element.
+ add support for multiple cache names
+ require each annotation to specify a cache name
+ add method support in Key generator interface
+ add bug fix for embedded JDK concurrent declaration
AbstractEnvironment delegates to an underlying ConfigurationService when
processing methods such as getProperty(String name, Class<?> targetType)
Accessor methods have been added to the ConfigurableEnvironment
interface that allow this service to be updated or replaced.
There is no longer a reserved default profile named 'default'. Rather,
users must explicitly specify a default profile or profiles via
ConfigurableEnvironment.setDefaultProfiles(String...)
- or -
spring.profile.default="pD1,pD2"
Per above, the setDefaultProfile(String) method now accepts a variable
number of profile names (one or more). This is symmetrical with the
existing setActiveProfiles(String...) method.
A typical scenario might involve setting both a default profile as a
servlet context property in web.xml and then setting an active profile
when deploying to production.
Before this change, the following properties could be used to manipulate
Spring profile behavior:
-DspringProfiles=p1,p2
-DdefaultSpringProfile=pD
These properties have been renamed to follow usual Java conventions for
property naming:
-Dspring.profile.active=p1,p2
-Dspring.profile.default=pD
'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.
Earlier naming reflected initial conception of 'environment-specific
bean definitions'. This notion has evolved into bean definitions
specific to particular profiles, and the new naming more clearly
expresses it.
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.
Embedded datasources now get their bean ids set as database name to allow multiple databases of the same type in parallel. Refactored tests a little and made BeanDefinitionParser package private to align with the other ones. Adapted changelog accordingly.
* documented that @Async can't be used in conjunction with lifecycle callbacks such as @PostConstruct
* provide sample for workaround
* added semantic markup for code
The shutdown mechanism for in-memory databases has changed since 10.6. We now have to trigger 'drop' instead of 'shutdown'. Besides that we can skip purging the database manually in newer versions.
- Relocate and fix typos in interface-based @RequestMapping tip (SPR-7537)
- Fix typos in constructor-arg 'name' disambiguation section (SPR-7443)
- Polish whitespace in DefaultServletHttpRequestHandler (SPR-7553)
Extended documentation to include hints on what to
consider when working with proxied controllers.
Explained the necessity of moving @RequestMapping
annotations to the interface or use proxy-target-
class="true".
When using PropertiesLoaderSupport implementations (principally
PropertyPlaceholderConfigurer), an assumption was made that any
Resource representing a set of properties must be file-based. SPR-7547
exposed the fact that if a non-file-based Resource implementation such
as ByteArrayResource were passed in, an IllegalStateException would be thrown
from the AbstractResource base class' implementation of getFilename().
This is now patched, and PropertiesLoaderSupport implementations treat
Resource implementations equally, regardless of file-orientation.
See also SPR-7552.
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.
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.
All <section/> elements in beans.xml >=~ 500 lines have been broken out
into separate documents with DOCTYPE 'section'. This refactoring makes
working with these files much easier in wysiwyg editors (namely
oXygen Author).
For consistency, this same refactoring should be applied to all other
chapters much larger than 1500 lines, such as aop.xml (3861), mvc.xml
(3466), jdbc.xml (3042), and so on.
beans.xml and the new section files have also been formatted for
consistency and to avoid whitespace diffs as much as possible into the
future.
JavaDoc and reference docs now warn developers against interacting with
bean instances within BeanFactoryPostProcessor implementations in order
to avoid premature bean instantiation.
See SPR-7450 for an example of a third-party BFPP
(OAuthTokenLifecycleRegistryPostProcessor) prematurely instantiating
a FactoryBean instance, such that bean post-processing is bypassed
and autowired injection (via @Inject) never occurs.
XFire is now CXF (per http://xfire.codehaus.org), and given that Spring
does not actually ship with any explicit XFire support, it makes sense
to remove the documentation completely. CXF does provide support for
writing services with Spring, and they provide their own documentation.
See http://cxf.apache.org/docs/writing-a-service-with-spring.html
Chapter 27 covered @Required and RequiredAnnotationBeanPostProcessor but
did not hold together as a chapter unto itself. The IoC chapter already
makes mention of @Required and RequiredAnnotationBeanPostProcessor,
though not in quite as much detail as Chapter 27 did. Links have been
updated throughout to reference these sections and Chatper 27 has been
eliminated entirely.
Prior to change, there were 175 instances of <methodname/> elements
including parentheses (e.g.: <methodname>foo()</methodname>, and
36 instances without.
Now all 211 instances include parentheses for consistency.
Documentation now:
- Reflects generic use of ApplicationListener interface
- Demonstrates use of ApplicationEventPublisher(Aware) instead of
ApplicationContext(Aware) for publishing custom events
- Provides a more complete narrative as to how each of the publisher,
listener, and event objects interact with one another
<programlisting/> elements must contain no newlines at beginning or end.
The following is an example of what not to do:
<programlisting><![CDATA[
package com.foo.bar;
class XFoo implements Foo<X> {
}]]>
</programlisting>
This leaves newlines at the beginning and end of the programlisting
panel within the PDF. Instead, do it like this:
<programlisting><![CDATA[package com.foo.bar;
class XFoo implements Foo<X> {
}]]></programlisting>
- The sentence at the end of section 5.5.5 now refers to the
<mvc:annotation-driven conversion-service="..."/> example at the end
of section 5.6.
- The sentence at the end of section 5.5.5 refers to the
FormatterConversionServiceFactoryBean section that follows.
- 'dependency-check' attribute of the <bean/> element was removed
in the spring-beans-3.0 XSD; documentation now reflects this change.
- 'autodetect' was removed from the enumeration of possible values
for autowire mode in the spring-beans-3.0 XSD; documentation now
reflects this change.
Note that the underlying functionality for these values has not been
removed from Spring Core. Users of Spring 3.0 who still need this
support may choose to use spring-beans-2.5.xsd in order to preserve
backward-compatibility.
Typo on the name of the @Autowired annotation: @Autowire -> @Autowired
Usage of the @Value annotation: ${jdbcProperties.url} -> ${jdbc.url} (inside section "Declaring @Configuration classes as plain Spring <bean/> elements").
This has been present for quite some time, and compilation at the
command line was never a problem. However, after upgrading to
STS 2.3.3.M2, errors started appearing in the Problems tab about
'duplicate @Aspect annotations'. This message was a bit misleading
given that the underlying issue is that applying an @Aspect annotation
on an aspect declared in .aj style is redundant. Andy Clement is
investigating as well, but for now the reason for the change in behavior
remains a mystery.
Hibernate validator had been updated to 4.1.0 in the ivy metadata, but
not yet reflected in the .classpath file. The pom.xml had been updated
but there was a typo - scope read 'coompile', instead of 'compile'.
All tests in ImportedConfigurationClassEnhancementTests now pass. The fix was simple - imported @Configuration class bean definitions were not getting marked with the attribute that indicates that they are indeed @Configuration class bean definitions. To make this happen, ConfigurationClassPostProcessor's protected checkConfigurationClassCandidate(beanDef) method is being called from within ConfigurationClassBeanDefinitionReader when imported @Configuration classes are being processed. This is quick and dirty, and the subsequent check-in will refactor the solution appropriately.
+ remove class definitions for sticking around (by forcing eager metadata initialization)
+ improve cache size by eliminating the numbers of method metadata objects created
+ improve lookup access on method metadata
+ improved example to work with multi-nested declarations
+ used JDK 5 syntax
+ added documentation code into trunk (including unit test) for easier future reference
This is where the master build that creates releases of Spring Framework resides. The build system is based on spring-build, which is linked in using an SVN external to https://src.springframework.org/svn/spring-build.
This is where the master build that creates releases of Spring Framework resides.
The build system is based on spring-build, which is linked in using an SVN
external to https://src.springframework.org/svn/spring-build.
Build Pre-requisites:
- javac 1.6 or > must be in your system path
- ant 1.7 or > must be in your system path
- set ANT_OPTS as follows (to avoid out of memory errors):
* wishing to add an {@link org.aopalliance.intercept.MethodInterceptor interceptor}
* to the resulting bean.
*
* <p>This base class controls the creation of the {@link ProxyFactoryBean} bean definition
* and wraps the original as an inner-bean definition for the <code>target</code> property of
* {@link ProxyFactoryBean}.
* and wraps the original as an inner-bean definition for the <code>target</code> property
* of {@link ProxyFactoryBean}.
*
* <p>Chaining is correctly handled, ensuring that only one {@link ProxyFactoryBean} definition
* is created. If a previous {@link org.springframework.beans.factory.xml.BeanDefinitionDecorator} already created the {@link org.springframework.aop.framework.ProxyFactoryBean}
* then the interceptor is simply added to the existing definition.
* is created. If a previous {@link org.springframework.beans.factory.xml.BeanDefinitionDecorator}
* already created the {@link org.springframework.aop.framework.ProxyFactoryBean} then the
* interceptor is simply added to the existing definition.
*
* <p>Subclasses have only to create the <code>BeanDefinition</code> to the interceptor they
* wish to add.
* <p>Subclasses have only to create the <code>BeanDefinition</code> to the interceptor that
throw new IllegalStateException("Not recording: Cannot set return value");
}
expectations.expectReturn(retVal);
}
public void expectThrowInternal(Throwable throwable) {
if (!recording) {
throw new IllegalStateException("Not recording: Cannot set throwable value");
}
expectations.expectThrow(throwable);
}
public void playbackInternal() {
recording = false;
}
}
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Spring Buildmaster