This commit also removes nullability from two common spots: ResolvableType.getType() and TargetSource.getTarget(), both of which are never effectively null with any regular implementation. For such scenarios, a non-null empty type/target is the cleaner contract.
Issue: SPR-15540
Beyond just formally declaring the current behavior, this revision actually enforces non-null behavior in selected signatures now, not tolerating null values anymore when not explicitly documented. It also changes some utility methods with historic null-in/null-out tolerance towards enforced non-null return values, making them a proper citizen in non-null assignments.
Some issues are left as to-do: in particular a thorough revision of spring-test, and a few tests with unclear failures (ignored as "TODO: NULLABLE") to be sorted out in a follow-up commit.
Issue: SPR-15540
This commit improves `AbstractValueAdaptingCache` to throw a dedicated
exception if `allowNullValues` is `false` and a `null` value is provided
anyway. This avoid a lower-level exception from the cache library that
will miss some context.
Issue: SPR-15173
Put the lambda parameter at the end and use a function
instead of a supplier to be able to register beans like this:
val context = GenericApplicationContext()
context.registerBean(Foo::class)
context.registerBean{ Bar(it.getBean(Foo::class)) }
Issue: SPR-15118
Based on an idea from Mario Arias, we can avoid requiring specifying
explicitly Supplier lambda type in Kotlin API by declaring the supplier
parameter as "crossinline supplier: () -> T" instead of
"supplier: Supplier<T>".
Issue: SPR-15118
This commit further refines 240f254 to also support java.util.Optional
for synchronized cache access (i.e. when the `sync` attribute on
`@Cacheable` is set to `true`).
Issue: SPR-14853
This commit makes sure that the `unregister` order of registered
application contexts has no incidence on the removal of the LiveBeansView
MBean.
Rather than using the last application context's name to compute the
identity of the MBean to remove, the identity is stored when the MBean is
created.
This commit also adds missing tests.
Issue: SPR-14848
String with version 5 the name of Java Platform, Enterprise Edition
changed from J2EE to Java EE. However a lot of the documentation still
uses the term J2EE.
This commit includes the following changes:
* replace J2EE with Java EE where appropriate
This is not a blind search and replace. The following occurrences
remain unchanged:
* references to old J2EE releases, most notably 1.3 and 1.4.
* references to "Expert One-On-One J2EE Design and Development"
* references to "Core J2EE patterns"
* XML namespaces
* package names
Issue: SPR-14811
See gh-1206
In order to simplify configuration for use cases involving @Bean where
only a bean name or aliases are supplied as an attribute, this commit
introduces a new 'value' attribute that is an @AliasFor 'name' in @Bean.
Issue: SPR-14728
This commit adds a "spring-context-indexer" module that can be added to
any project in order to generate an index of candidate components defined
in the project.
`CandidateComponentsIndexer` is a standard annotation processor that
looks for source files with target annotations (typically `@Component`)
and references them in a `META-INF/spring.components` generated file.
Each entry in the index is the fully qualified name of a candidate
component and the comma-separated list of stereotypes that apply to that
candidate. A typical example of a stereotype is `@Component`. If a
project has a `com.example.FooService` annotated with `@Component` the
following `META-INF/spring.components` file is generated at compile time:
```
com.example.FooService=org.springframework.stereotype.Component
```
A new `@Indexed` annotation can be added on any annotation to instructs
the scanner to include a source file that contains that annotation. For
instance, `@Component` is meta-annotated with `@Indexed` now and adding
`@Indexed` to more annotation types will transparently improve the index
with additional information. This also works for interaces or parent
classes: adding `@Indexed` on a `Repository` base interface means that
the indexed can be queried for its implementation by using the fully
qualified name of the `Repository` interface.
The indexer also adds any class or interface that has a type-level
annotation from the `javax` package. This includes obviously JPA
(`@Entity` and related) but also CDI (`@Named`, `@ManagedBean`) and
servlet annotations (i.e. `@WebFilter`). These are meant to handle
cases where a component needs to identify candidates and use classpath
scanning currently.
If a `package-info.java` file exists, the package is registered using
a "package-info" stereotype.
Such files can later be reused by the `ApplicationContext` to avoid
using component scan. A global `CandidateComponentsIndex` can be easily
loaded from the current classpath using `CandidateComponentsIndexLoader`.
The core framework uses such infrastructure in two areas: to retrieve
the candidate `@Component`s and to build a default `PersistenceUnitInfo`.
Rather than scanning the classpath and using ASM to identify candidates,
the index is used if present.
As long as the include filters refer to an annotation that is directly
annotated with `@Indexed` or an assignable type that is directly
annotated with `@Indexed`, the index can be used since a dedicated entry
wil be present for that type. If any other unsupported include filter is
specified, we fallback on classpath scanning.
In case the index is incomplete or cannot be used, The
`spring.index.ignore` system property can be set to `true` or,
alternatively, in a "spring.properties" at the root of the classpath.
Issue: SPR-11890
This commit adds a test runtime dependency on log4j 2 for every project
and migrates all log4j.properties files to log4j2-test.xml files.
Issue: SPR-14431
Prior to Java 8 it never really made much sense to author integration
tests using interfaces. Consequently, the Spring TestContext Framework
has never supported finding test-related annotations on interfaces in
its search algorithms.
However, Java 8's support for interface default methods introduces new
testing use cases for which it makes sense to declare test
configuration (e.g., @ContextConfiguration, etc.) on an interface
containing default methods instead of on an abstract base class.
This commit ensures that all non-repeatable, class-level test
annotations in the Spring TestContext Framework can now be declared on
test interfaces. The only test annotations that cannot be declared on
interfaces are therefore @Sql and @SqlGroup.
Issue: SPR-14184
It's handy to know in advance whether or not expression that is
passed to CronSequenceGenerator or CronTrigger constructor would
not results in IllegalArgumentException. The only way to do it
now is to try\catch an instance creation but it's kinda ugly.
This commit makes sure to reject an `@EventListener` annotated method
that also uses `@Async`. In such scenario, the method is invoked in a
separate thread and the infrastructure has no handle on the actual reply,
if any.
The documentation has been improved to refer to that scenario.
Issue: SPR-14113
This commit reverts the recently added merged annotation support for
Spring's JMX annotations by once again using the simpler searches for
repeatable annotations in AnnotationUtils.
Issue: SPR-13973
Prior to this commit, @Cacheable, @CacheEvict, @CachePut, and @Caching
could be used to create custom stereotype annotations with hardcoded
values for their attributes; however, it was not possible to create
composed annotations with attribute overrides.
This commit addresses this issue by refactoring
SpringCacheAnnotationParser to use the newly introduced
findAllMergedAnnotations() method in AnnotatedElementUtils. As a
result, @Cacheable, @CacheEvict, @CachePut, and @Caching can now be
used to create custom composed annotations with attribute overrides
configured via @AliasFor.
Issue: SPR-13475
Previously, a package private `@ManagedResource` annotated bean was
registered to the JMX domain even if any attempt to invoke an operation
on it will fail since it has to be public.
This commit validates that any `@ManagedResource` annotated bean is
public and throws an InvalidMetadataException otherwise. Note that the
actual bean type does not have to be public as long as the class
annotated with `@ManagedResource` in the hierarchy is pubic and no extra
operations or attributes are defined on the child.
Issue: SPR-14042
Previously, the generic type of a simple pojo event implementing
ResolvableTypeProvider wasn't detected properly. This commit fixes the
logic when the generic type is not provided to reuse what
PayloadApplicationEvent is already doing anyway.
Issue: SPR-14029
Prior to this change SpEL did not have an syntactic
construct enabling easy access to a FactoryBean. With this
change it is now possible to use &foo in an expression when
the factory bean should be returned.
Issue: SPR-9511
ConcurrentMapCacheManager and ConcurrentMapCache now support the
serialization of cache entries via a new `storeByValue` attribute. If it is
explicitly enabled, the cache value is first serialized and that content
is stored in the cache.
The net result is that any further change made on the object returned
from the annotated method is not applied on the copy held in the cache.
Issue: SPR-13758
Previously, if a `@Cacheable` method was accessed with the same key by
multiple threads, the underlying method was invoked several times instead
of blocking the threads while the value is computed. This scenario
typically affects users that enable caching to avoid calling a costly
method too often. When said method can be invoked by an arbitrary number
of clients on startup, caching has close to no effect.
This commit adds a new method on `Cache` that implements the read-through
pattern:
```
<T> T get(Object key, Callable<T> valueLoader);
```
If an entry for a given key is not found, the specified `Callable` is
invoked to "load" the value and cache it before returning it to the
caller. Because the entire operation is managed by the underlying cache
provider, it is much more easier to guarantee that the loader (e.g. the
annotated method) will be called only once in case of concurrent access.
A new `sync` attribute to the `@Cacheable` annotation has been addded.
When this flag is enabled, the caching abstraction invokes the new
`Cache` method define above. This new mode bring a set of limitations:
* It can't be combined with other cache operations
* Only one `@Cacheable` operation can be specified
* Only one cache is allowed
* `condition` and `unless` attribute are not supported
The rationale behind those limitations is that the underlying Cache is
taking care of the actual caching operation so we can't really apply
any SpEL or multiple caches handling there.
Issue: SPR-9254
Previously, if a managed bean had only one non-default constructor, we
should still annotate it with `@Autowired` to properly use constructor
injection. Not doing so resulted in an error as the container was
trying to call the default (non-existing) constructor.
This commit updates this behaviour to automatically applyed the
autowiring semantic to any bean that has only one constructor. As
before, if more than one constructor is defined, `@Autowired` must be
specified to teach the container the constructor it has to use.
Issue: SPR-12278
With this change the MapAccessor now extends CompilablePropertyAccessor
rather than just PropertyAccessor. This means that any expression that
ends up using the MapAccessor is now compilable for fast performance.
Issue: SPR-13638
Even though the JSR-107 spec forbids to store null values, our cache
abstraction allows that behaviour with a special handled (and this is
the default behaviour).
While this was working fine with our own set of annotations, the
JSR-107 interceptor counterpart was interpreting the spec sensu strictu.
We now allow for that special case as well.
Issue: SPR-13641
This commit migrates all remaining tests from JUnit 3 to JUnit 4, with
the exception of Spring's legacy JUnit 3.8 based testing framework that
is still in use in the spring-orm module.
Issue: SPR-13514
This commit introduces ignored, failing tests that demonstrate that the
@Cache* annotations are not yet supported as merged composed annotations.
Issue: SPR-13475
In addition to specifying the event type to listen to via a method
parameter, any @EventListener annotated method can now alternatively
define the event type(s) to listen to via the "classes" attributes (that
is aliased to "value").
Something like
@EventListener({FooEvent.class, BarEvent.class})
public void handleFooBar() { .... }
Issue: SPR-13156
Provide a mean to detect the actual ResolvableType based on a instance as
a counter measure to type erasure.
Upgrade the event infrastructure to detect if the event (or the payload)
implements such interface. When this is the case, the return value of
`getResolvableType` is used to validate its generic type against the
method signature of the listener.
Issue: SPR-13069
While working on SPR-12532, an extra IdentityWrapper was added to work
around a backward compatible issue between commons pool 1.x and 2.x. This
issue (POOL-283) has actually been fixed in 2.4 and their IdentityWrapper
is using object equality so our wrapper is in the way.
Looking retrospectively, the code looks all fine without the workaround
and commons pool 2.4 or later so it has been removed.
Since Spring 4.1, a CacheResolver may be configured to customize the way
the cache(s) to use for a given cache operation are retrieved. Since a
CacheResolver implementation may not use the cache names information at
all, this attribute has been made optional.
However, a fix was still applied, preventing a Cache operation without a
cache name to be defined properly. We now allow this valid use case.
Issue: SPR-13081
This commit introduces new 'cacheNames' attributes (analogous to the
existing attribute of the same name in @CacheConfig) as aliases for the
'value' attributes in @Cacheable, @CachePut, and @CacheEvict.
In addition, SpringCacheAnnotationParser.getAnnotations() has been
refactored to support synthesized annotations.
Issue: SPR-11393
Previously, a Bean implementing `AutoCloseable` (or `Closeable`) was
always destroyed regardless of its bean definition. In particular, the
documented way of disabling the destruction callback via an empty String
did not work.
AutoCloseable beans are now treated pretty much as any other bean: we
still use the presence of the interface to optimize the check of a
destroy method and we only auto-discover the method name to invoke if
the inferred mode is enabled.
Issue: SPR-13022
Covers ReflectionUtils.doWithMethods as well as affected annotation post-processors.
Includes an extension of MethodMetadata for the detection of @Bean default methods.
Issue: SPR-12822
Issue: SPR-10919
If a sub-class of Future (such as ListenableFuture) is used as a return
type and an exception is thrown, the AsyncUncaughtExceptionHandler is
called. Now checking for any Future implementation instead of a faulty
strict matching.
Issue: SPR-12797
This commit ensures that @NumberFormat can be used as a
meta-annotation, as was already the case for @DateTimeFormat.
In addition, this commit polishes FormattingConversionServiceTests and
MvcNamespaceTests.
Issue: SPR-12743
Prior to this commit, the GroovyBeanDefinitionReader claimed (via its
Javadoc) that it fully supported XML configuration files in addition to
its Groovy DSL; however, this was unfortunately inaccurate since XML
validation was disabled by default which led to certain features of XML
configuration not working. For example, it was impossible to define a
<qualifier> in an XML config file without specifying the 'type'
attribute (which has a default value defined in the spring-beans XSD).
This commit fixes this issue by ensuring that bean definitions in XML
resources are loaded with a "standard" XmlBeanDefinitionReader that is
created with default settings (i.e., with XML validation enabled). With
regard to backwards compatibility, bean definitions defined using the
Groovy DSL are still loaded with an XmlBeanDefinitionReader that has
XML validation disabled by default which is necessary for proper
parsing of the Groovy DSL.
Issue: SPR-12769
If an `@EventListener` annotated method returns a Collection or an Array,
each individual items are now published as an event instead of publishing
one event with said collection.
Issue: SPR-12733
Deprecated CommonsPoolTargetSource (supporting commons pool 1.5+) in
favor of CommonsPool2TargetSource with a similar contract.
Commons Pool 2.x uses object equality while Commons Pool 1.x used
identity equality. This clearly means that Commons Pool 2 behaves
differently if several instances having the same identity according to
their `Object#equals(Object)` method are managed in the same pool. To
provide a smooth upgrade, a backward-compatible pool is created by
default; use `setUseObjectEquality(boolean)` if you need the standard
Commons Pool 2.x behavior.
Issue: SPR-12532
Previously, the `@Order` annotation was managed in an inconsistent way
when placed at the implementation level. For simple beans, it was
discovered properly but wasn't for beans requiring a proxy.
OrderComparator.SourceProvider now explicitly allows to return several
order sources; the default implementation returns not only the factory
method (if any) but also the target class if it happens to be different
from the class of the bean.
Issue: SPR-12636
Previously, the exception-handler attribute was not taken care of when
task:annotation-driven is used in AspectJ mode. This commit provides the
expected behavior.
Issue: SPR-12619
Update the application event listener infrastructure to support events
that are processed according to a transactional phase.
Introduce EventListenerFactory that can be implemented to provide support
for additional event listener types. TransactionalEventListener is a new
annotation that can be used in lieu of the regular EventListener. Its
related factory implementation is registered in the context automatically
via @EnableTransactionManagement or <tx:annotation-driven/>
By default, a TransactionalEventListener is invoked when the transaction
has completed successfully (i.e. AFTER_COMMIT). Additional phases are
provided to handle BEFORE_COMMIT and AFTER_ROLLBACK events.
If no transaction is running, such listener is not invoked at all unless
the `fallbackExecution` flag has been explicitly set.
Issue: SPR-12080
Add support for annotation-based event listeners. Enabled automatically
when using Java configuration or can be enabled explicitly via the
regular <context:annotation-driven/> XML element. Detect methods of
managed beans annotated with @EventListener, either directly or through
a meta-annotation.
Annotated methods must define the event type they listen to as a single
parameter argument. Events are automatically filtered out according to
the method signature. When additional runtime filtering is required, one
can specify the `condition` attribute of the annotation that defines a
SpEL expression that should match to actually invoke the method for a
particular event. The root context exposes the actual `event`
(`#root.event`) and method arguments (`#root.args`). Individual method
arguments are also exposed via either the `a` or `p` alias (`#a0` refers
to the first method argument). Finally, methods arguments are exposed via
their names if that information can be discovered.
Events can be either an ApplicationEvent or any arbitrary payload. Such
payload is wrapped automatically in a PayloadApplicationEvent and managed
explicitly internally. As a result, users can now publish and listen
for arbitrary objects.
If an annotated method has a return value, an non null result is actually
published as a new event, something like:
@EventListener
public FooEvent handle(BarEvent event) { ... }
Events can be handled in an aynchronous manner by adding `@Async` to the
event method declaration and enabling such infrastructure. Events can
also be ordered by adding an `@Order` annotation to the event method.
Issue: SPR-11622
Update the event publishing infrastructure to support generics-based
events, that is support ApplicationListener implementations that define
a generic event, something like:
public class MyListener
implements ApplicationListener<GenericEvent<String>> { ... }
This listener should only receive events that are matching the generic
signature, for instance:
public class StringEvent extends GenericEvent<String> { ... }
Note that because of type erasure, publishing an event that defines the
generic type at the instance level will not work. In other words,
publishing "new GenericEvent<String>" will not work as expected as type
erasure will define it as GenericEvent<?>.
To support this feature, use the new GenericApplicationListener that
supersedes SmartApplicationListener to handle generics-based even types via
`supportsEventType` that takes a ResolvableType instance instead of the
simple Class of the event. ApplicationEventMulticaster has an additional
method to multicast an event based on the event and its ResolvableType.
Issue: SPR-8201
Previously, one could only set the list of bean names to exclude from
auto-detection and there was no way to add additional bean names.
MBeanExporter now exposes a addExcludedBean method that can be invoked
during the initialization phase to add bean names to ignore.
Issue: SPR-12686
Move MethodCacheKey and related classes to the expression package so that
other parts of the framework can benefit ot it.
CacheExpressionEvaluator is a base class that can be used to cache SpEL
expressions based on its annotation source (i.e. method). Sub-classing
that base class provides a simple to use API to retrieve Expression
instances efficiently.
Issue: SPR-12622
This commit overhauls several of the tests that interact with an
MBeanServer with the goal of increasing the reliability of these tests.
- MBeanClientInterceptorTests now uses JUnit "assumptions" instead of
preemptively returning from test methods, thus allowing such methods
to be properly marked as "ignored" instead of "passed".
- MBeanClientInterceptorTests now uses JUnit's support for expected
exceptions where appropriate.
- MBeanClientInterceptorTests and RemoteMBeanClientInterceptorTests now
use Spring's SocketUtils to find an available TCP port when starting
an MBeanServer instead of aborting the tests when the default JMX
port is not available.
Issue: SPR-12601
Commit 65d163e changed the textual message of an exception thrown by
ScheduledAnnotationBeanPostProcessor.afterSingletonsInstantiated(), and
this in turn caused the withAmbiguousTaskSchedulers_andSingleTask()
method in EnableSchedulingTests to start failing (albeit only during
'Performance' builds).
This commit updates the assertion to match the current implementation of
ScheduledAnnotationBeanPostProcessor.
Previously, if a bean has a scoped proxy and is annotated to be exposed
to the JMX domain, both the scoped proxy and the target instance were
exposed in the JMX domain, resulting in a duplicate entries. Worse, if
such bean defines an explicit name, the application wouldn't start
because of a name conflict.
This commit deals explicitely with scoped proxy and make sure to only
expose the relevant bean.
Issue: SPR-12529
Previously, any @Configuration class was enhanced to namely implement
DisposableBean in order to remove static callbacks that were registered
for that class. This leads to problem if an ApplicationContext is created
and destroyed within the lifecycle on another ApplicationContext in the
same class loader.
It turns out that the destruction callback is no longer necessary as the
interceptors are now stateless: the VM is free to reclaim any of those if
necessary.
Issue: SPR-12445
The removed test testConfigFileParsingErrorWhenNamedBeans() could cause
a groovyc compilation error, for example when using latest IntelliJ IDEA.
Issue: SPR-12435
Prior to this commmit, any configuration class holding a CacheManager
bean would be eagerly instantiated. This is because the
CacheConfiguration infrastructure requests all beans of type
CacheManager.
This commit defers the resolution of the CacheManager as late
as possible.
Issue: SPR-12336
Refine the logic introduced in commit 71c6eb2b so that additional
imported @Configuration classes are not considered as candidates if
they have already been parsed.
Issue: SPR-12233
Refine property source ordering so that sources already contained in the
environment remain before those added by @PropertySource annotations.
Issue: SPR-12198
Update JndiLocatorDelegate.isDefaultJndiEnvironmentAvailable() to
call `getEnvironment()` on the `InitialContext` in order to actually
trigger a NamingException if JNDI is not available.
Issue: SPR-12223
Update ImportRegistry to track all import registrations that occur
against an importing class (rather than just keeping the last). In
addition, prune imported classes from the registry when a configuration
class is removed during the REGISTER_BEAN ConfigurationPhase.
This update prevents incorrect metadata from being injected into an
ImportAware class which is imported twice by different configurations
classes (when one of the configuration classes will be ultimately skipped
due to a @Condition).
Issue: SPR-12128
Rework the @PropertySource parsing logic recently changed in commit
7c608886 to deal with the same source appearing on a @Configuration
class and an @Import class.
Processing now occurs in a single sweep, with any previously added
sources being converted to a CompositePropertySource.
Issue: SPR-12115
Other PropertySources and in particular @ComponentScan can benefit from previously declared property sources on the same configuration class.
Issue: SPR-12110
Issue: SPR-12111
Also contains refined exception handling, treating regular class loading and ASM-based loading consistently in terms of exception wrapping, and always mentioning the current configuration class in all exception messages.
Issue: SPR-11997
This commit removes the immediate package dependency cycle between the context and jmx packages. A specific callback arrangement will follow in time for 4.1 RC1; at this point, it's temporarily back to registration kicked off by afterPropertiesSet again.
Issue: SPR-8045
Commit eea230f introduced a regression by adding a support for the
"result" variable in SpEL expression for @CachePut. As such expressions
cannot be evaluated upfront anymore, any method that contains both
@Cacheable and @CachePut annotations are always executed even when
their conditions are mutually exclusive.
This is an example of such mutual exclusion
@Cacheable(condition = "#p1", key = "#p0")
@CachePut(condition = "!#p1", key = "#p0")
public Object getFooById(Object id, boolean flag) { ... }
This commit updates CacheEvaluationContext to define a set of
unavailable variables. When such variable is accessed for a given
expression, an exception is thrown. This is used to restore the
evaluation of the @CachePut condition upfront by registering "result"
as an unavailable variable.
If all @CachePut operations have been excluded by this upfront check,
the @Cacheable operation is processed as it was before. Such upfront
check restore the behavior prior to eea230f.
Issue: SPR-11955
This commit validates that the changes introduced in 8221c9abc5 are
indeed allowing DirectFieldBindingResult to support nested validation
paths.
Issue: SPR-10623
Reorganized class structure to match our code style (setter for
properties at the top of the class, public method before private
implementation).
Removed DisposableBean as it the lifecycle is already taking care
of removing MBeans on stop.
Cleaned test suite
Issue: SPR-8045
Prior to this commit, MBeans were registered in a post construct
call of MBeanExporter. This commit moves that logic after the
initialization phase using the SmartLifecycle callback.
Issue: SPR-8045
This commit introduces OrderProvider and OrderProviderComparator, two
interfaces designed to externalize how a collection of element is sorted
according to their order value.
FactoryAwareOrderProvider is an OrderProvider implementation that knows
about the objects to order and the corresponding BeanFactory instance.
This allows to retrieve additional metadata about the actual instances
to sort, such as its factory method.
A @Bean method can now holds an additional @Order to define the order
value that this bean should have when injected as part of a collection
or array.
Issue: SPR-11310
This commit adds a invokeOperation protected method in case one
needs a hook point in the way the underlying cache method is invoked,
and how exceptions that might be thrown by that invocation are handled.
Issue: SPR-11540
Prior to this commit, CacheResolver could not be configured through
the XML namespace (i.e. cache:annotation-driven). This is now the
case.
Issue: SPR-11490
This commit adds the necessary infrastructure to handle exceptions
thrown by a cache provider in both Spring's and JCache's caching
abstractions.
Both interceptors can be configured with a CacheErrorHandler that
defines several callbacks on typical cache operations. In particular,
handleCacheGetError can be implemented in such a way that an
exception thrown by the provider is handled as a cache miss by the
caching abstraction.
The handler can be configured with both CachingConfigurer and the
XML namespace (error-handler property)
Issue: SPR-9275
Prior to this commit, only the java.lang.reflect.Method was used to
identify an annotated method. As a result, if different annotations
were placed on different methods (method overriding, interface
implementation) only the first one (cached) was used.
LazyParamAwareEvaluationContext was affected by the exact
same problem and has been also fixed.
Issue: SPR-11692
Prior to this commit, the CacheResolver was not used by Spring's
caching abstraction. This commit provides the necessary configuration
options to tune how a cache is resolved for a given operation.
CacheResolver can be customized globally, at the operation level or at
the class level. This breaks the CachingConfigurer class and a support
implementation is provided that implements all methods so that the
default is taken if it's not overridden. The JSR-107 support has been
updated as well, with a similar support class.
In particular, the static and runtime information of a cache
operation were mixed which prevents any forms of caching. As the
CacheResolver and the KeyGenerator can be customized, every operation
call lead to a lookup in the context for the bean.
This commit adds CacheOperationMetadata, a static holder of all
the non-runtime metadata about a cache operation. This is used
as an input source for the existing CacheOperationContext.
Caching the operation metadata in an AspectJ aspect can have side
effects as the aspect is static instance for the current ClassLoader.
The metadata cache needs to be cleared when the context shutdowns.
This is essentially a test issue only as in practice each application
runs in its class loader. Tests are now closing the context properly
to honor the DisposableBean callback.
Issue: SPR-11490
This commit adds a putIfAbsent method to the Cache interface. This
method offers an atomic put if the key is not already associated in
the cache.
Issue: SPR-11400
Prior to this commit, an exception thrown by an @Async void method
was not further processed as there is no way to transmit that
exception to the caller.
The AsyncUncaughtExceptionHandler is a new strategy interface that
can be implemented to handle unexpected exception thrown during the
invocation of such asynchronous method.
The handler can be specified using either the XML namespace or by
implementing the AsyncConfigurer interface with the EnableAsync
annotation.
Issue: SPR-8995
Prior to this commit, common cache operation settings had to be
repeated for every operation: cache name(s), custom cache manager
and custom key manager.
This commit introduces the @CacheConfig annotation to bet set at
class-level (either directly or as a meta-annotation). As the cache
name(s) can be rationalized there, the "value" of the various
annotations are no longer mandatory.
CacheAnnotationParser has an API breakage to be able to retrieve
information at class-level.
Issue: SPR-11316
It is now possible to specify the CacheManager to use per operation.
The related cache annotation now has an extra attribute that defines
the name of the CacheManager bean to use. The cache manager that
was previously used is therefore a 'default' cache manager (i.e. the
one to use if no custom cache manager has been set on the operation).
Issue: SPR-8696
This commit adds an extra parameter to the base @Cache method
annotations: keyGenerator. This parameter holds the name of the
KeyGenerator bean to use to compute the key for that specific
caching endpoint.
This gives therefore a third way to customize the key. These are:
1. Default KeyGenerator (global for all endpoints)
2. The 'key' attribute of the annotation, giving the SpEL expression to use
3. The 'keyGenerator' attribute of the annotation
The annotation attributes are therefore exclusive. Trying to specify
them both will result in an IllegalStateException.
The KeyGenerator to use for a given operation is cached on startup
so that multiple calls to it does not resolve the instance to use over and
over again.
Issue: SPR-10629
Prior to this commit, the codebase was using a mix of log4j.xml
and log4j.properties for test-related logging configuration. This
can be an issue as log4j takes the xml variant first when looking
for a default bootstrap configuration.
In practice, some modules declaring the properties variant were
taking the xml variant configuration from another module.
The general structure of the configuration has also been
harmonized to provide a standard console output as well as an
easy way to enable trace logs for the current module.
Prior to this commit, Spring supported meta-annotation attribute
overrides in custom composed annotations with reflection-based
annotation processing but not with ASM-based annotation processing.
This commit ensures that meta-annotation attribute overrides are
supported in AnnotationMetadataReadingVisitor.getAnnotationAttributes().
Issue: SPR-11574
Prior to this commit, AnnotationAttributesReadingVisitor treated Class
annotation attributes as Strings instead of Classes. As a result,
look-ups for Class attributes in meta-annotations failed with an
IllegalArgumentException.
This commit fixes this issue by consistently treating Class attributes
as Classes in AnnotationAttributesReadingVisitor.
Issue: SPR-11557
This commit introduces unit and integration tests that attempt to
reproduce the issue claimed by the reporter in SPR-11557. However, the
tests pass without any problems.
Issue: SPR-11557
Restored original singleton-only adaptInnerBeanName behavior, avoiding endless unique name calculation for every single prototype instance. Non-named inner BeanDefinition objects now suffixed with an identity hex code analogous to non-named XML bean definitions, largely avoiding naming collisions to begin with. After SPR-11246, post-processors can deal with unstable classes per bean name, so occasional collisions aren't a hard problem anymore.
Issue: SPR-11545
Prior to this commit, an array argument was not handled properly in
SimpleKey#equals and SimpleKey#hashCode. As a result, two method
invocations with the same array argument lead to two different keys
and therefore two different entries in the cache.
This commit uses deepEquals and deepHashCode to properly handle
methods that have arguments that are array types.
Issue: SPR-11505
This commit continues the work for fixing memory leaks resulting from
CGLIB subclass generation for beans relying on method injection.
- Set proxy callbacks on the CGLIB Factory (i.e., the instance) instead
of in the generated subclass (i.e., via the Enhancer).
- Convert private inner classes in CglibSubclassingInstantiationStrategy
to private static classes in order to avoid unnecessary coupling to
classes generated using CGLIB.
- Tidy up XmlBeanFactoryTests.
- Update logic in serializableMethodReplacerAndSuperclass() so that it
finally aligns with the decision made for SPR-356.
Issue: SPR-10785, SPR-356
This commit introduces a test in XmlBeanFactoryTests that verifies that
CGLIB generated subclasses for method injected beans are reused across
bean factories for identical bean definitions. In other words, by
verifying that the same CGLIB generated class is reused for identical
bean definitions, we can be certain that Spring is no longer generating
identical, duplicate classes that consume memory in the VM.
Issue: SPR-10785, SPR-11420
- Consistent importing of org.junit.Assert.*;
- Proper declaration of expected exceptions via @Test(expected).
- Renamed SpEL ExpressionTestCase to AbstractExpressionTests.
- Formatting and test method naming conventions.
Prior to this commit several test classes named "*Test" were not
recognized as tests by the Gradle build. This is due to the configured
inclusion of '**/*Tests.*' which follows Spring's naming convention for
test classes.
This commit addresses this issue by:
- Renaming real test classes consistently to "*Tests".
- Renaming internal test classes to "*TestCase".
- Renaming @WebTest to @WebTestStereotype.
- Disabling broken tests in AnnoDrivenStaticEntityMockingControlTest.
- Modifying the Gradle build configuration so that classes ending in
either "*Tests" or "*Test" are considered test classes.
Issue: SPR-11384
Stereotype annotations should support a 'value' attribute for
specifying the name of the Spring-managed component; however,
@RestController currently does not provide such an attribute.
This commit introduces a 'value' attribute in @RestController so that
developers can provide custom names for components annotated with
@RestController.
Issue: SPR-11360
This turned out to be a bug in the ASM-based AnnotationMetadata implementation where has/getAnnotatedMethods didn't consider meta-annotations., in contrast to its StandardAnnotationMetadata sibling.
Issue: SPR-10488
Specifically, if the current factory has Qualifier/ContextAnnotationAutowireCandidateResolver set up, it is important to pass it on to ancestor factories to get consistent qualifier matching results.
Issue: SPR-10966
Our per-bean caching in AutowiredAnnotationBeanPostProcessor and co relies on unique bean names, so this change fixes potential cache mismatch problems occuring there.
Issue: SPR-11131
Fix CacheAspectSupport to consider a cache hit from any of the multiple
@Cachables that may have been specified using the @Caching annotation.
Prior to this commit the following scenario would never produce a hit:
@Caching(cacheable = {
@Cacheable(value = "c1", unless = "#result.size() < 4"),
@Cacheable(value = "c2", unless = "#result.size() > 3")
})
Issue: SPR-11124
Apply consistent styling to new classes introduced in Spring 4.0.
- Javadoc line wrapping, whitespace and formatting
- General code whitespace
- Consistent Assert.notNull messages
Delete the unused GlassFishLoadTimeWeaverTests and in the process
fix the "Unable to load JUnit4 runner to calculate Ignored test cases"
Gradle error.
Issue: SPR-10563
Fix remaining Java compiler warnings, mainly around missing
generics or deprecated code.
Also add the `-Werror` compiler option to ensure that any future
warnings will fail the build.
Issue: SPR-11064
- Cache interceptor internals now operate on collections of
<? extends Cache> instead of <Cache>.
- Deleted unused imports.
- Deleted dead code.
- Suppressed warnings for resource leaks related to not closing
ApplicationContexts in tests.
- Suppressed further non-issue warnings in tests.
@Bean method metadata is always being picked from the most concrete subclass; @Bean method overloads are allowed within the same config class as well; and @Bean overrides and overloads work with 'allowBeanDefinitionOverriding'=false now.
Issue: SPR-10992
Issue: SPR-11025
This new get variant not only allows for generically specifying the required value type; it also skips the ValueWrapper that the standard get method returns. Note that it is not possible to differentiate between non-existing cache entries and cached null values that way; for that purpose, the standard get variant needs to be used.
Issue: SPR-11061
Since @Bean methods are never used with externally specified constructor argument values but rather just with autowiring, the non-lenient constructor resolution mode is appropriate in case of an overloaded @Bean method, not performing any type difference weight checks. This change includes a refinement of Spring's existing non-lenient constructor resolution (which needs to be explicitly turned on and is therefore not well tested), narrowing the conditions for the ambiguity check (only in case of the same number of arguments and not for overridden methods).
Issue: SPR-10988
Including ScriptEvaluator implementations for JSR-223, Groovy and BeanShell. BeanShell consistently receives the bean ClassLoader now. Also revised ScriptFactory and its implementations for varargs.
Issue: SPR-11007
Introduce base class AbstractMethodMessageHandler for
HandlerMethod-based message handling.
Add MessageCondition interface for mapping conditions to messages
with support for combining type- and method-level annotation
conditions, the ability to match conditions to messages, and also
comparing matches to select the best match.
Issue: SPR-11024
Support repeatable @PropertySource annotations in Java 8 and add
@PropertySources container annotation for Java 6/7. Also add an
ignoreResourceNotFound attribute to @PropertySource allowing missing
property resources to be silently ignored.
This commit also introduces some generally useful methods to
AnnotationUtils for working with @Repeatable annotations.
Issue: SPR-8371
Ensure that property source locations are processed in the same order
regardless if the 'name' attribute is set or not.
Prior to this commit multiple locations from a `@PropertySource` with
a name were added to a `CompositePropertySource` in such a way that
the first location would take precedence. This has now been reversed
for consistence with unnamed `@PropertySource`s
Issue: SPR-10820
Update `AbstractApplicationEventMulticaster` to support `EventObjects`
with a null source (which can happen if they have been serialized).
Issue: SPR-10945
Includes revisions of MethodParameter and DependencyDescriptor (in particular towards a reference to the containing class). Also refines several ResolvableType method signatures.
Issue: SPR-9965
Update `CacheAspectSupport` to expand any var-arg parameters before
calling `KeyGenerator` implementations. Prior to this commit var-args
would be passed to `KeyGenerator` implementations as a nested array,
often causing the same key to be generated regardless of the arguments.
Issue: SPR-10870
Extended DefaultAopProxyFactory to create Objenesis based proxies if the
library is on the classpath. This allows classes without a default
constructor being CGLib proxied. We're now falling back to original CGLib
based behavior in case the proxy creation using Objenesis fails.
Objenesis 2.0 is now inlined into spring-core to avoid interfering with
other Objenesis versions on the classpath.
Issue: SPR-10594
Also, DefaultListableBeanFactory logs a warning when overriding an application definition with a framework-generated definition now, which is expected to be an accident.
Issue: SPR-10607
We're using the same subtle PriorityOrdered/Ordered/non-ordered separation as for regular BeanFactoryPostProcessors and BeanPostProcessors now. Additionally, we're re-detecting BeanDefinitionRegistryPostProcessor bean names after every invocation phase, up until no further ones appear.
Issue: SPR-10630
This turned into a rather huge affair since it led to the introduction of a new AutowireCandidateResolver implementation in the spring-context module. That ACR impl is now being set through AnnotationConfigUtils; GenericApplicationContext and co do not set a default QualifierAnnotationAutowireCandidateResolver anymore (which has always been a smell anyway). At the same time, dependency ordering has moved from AutowiredAnnotationBeanPostProcessor to DefaultListableBeanFactory itself through a "dependencyComparator" strategy, applying to constructor dependencies and lazy resolution proxies as well.
Issue: SPR-10353
Fix @Condition evaluation to also consider super classes for both
@Configuration classes and regular @Components. This change allows
@Conditional annotations to be inherited and restores the previous
behavior of @Profile.
Issue: SPR-10840
Also fixing an old XmlBeanFactory test that relies on "ref local" which is gone in the 4.0 xsd now, redeclaring the affected file to an older xsd version.
Allow the @CachePut 'key' SpEL to refer to the result of the method call
via a '#result' variable.
This change is particularly useful when working with JPA entities that
have generated @Id values since the ID will often not be available
until the entity has been saved.
Issue: SPR-10664
Introduce new SimpleKeyGenerator class to supersede DefaultKeyGenerator.
Unlike DefaultKeyGenerator, no collisions will occur with the keys
generated by SimpleKeyGenerator as the full parameter values are
considered within the SimpleKey.equals(...) method.
The SimpleKeyGenerator is now the default class used when no explicit
generator is configured.
Issue: SPR-10237
Add EnhancedConfigurationBeanPostProcessor to inject the BeanFactory
into EnhancedConfiguration classes before the
AutowiredAnnotationBeanPostProcessor.postProcessPropertyValues method
is called.
Prior to this commit it was possible for @Autowire in a @Configuration
class to invoke an enhanced configuration class method before the
BeanFactory was injected. This is due to the fact that the
AutowiredAnnotationBeanPostProcessor was called before
AbstractAutowireCapableBeanFactory.invokeAwareMethods().
Issue: SPR-10668
Introduce new ConfigurationCondition interface allowing more
fine-grained control for @Conditional when used with @Configuration
beans.
Primarily added so that the evaluation of conditions that inspect bean
definitions can be deferred until all @Configuration classes have been
parsed.
Issue: SPR-10534
Defer @Conditional processing on @Configuration classes until the bean
definitions are loaded, rather than when the @Configuration class is
parsed. This provides better support for @Conditional implementations
that inspect bean definitions.
This commit also fixes some minor problems with original implementation
and replaces the ConditionalAnnotationHelper class with
ConditionEvaluator.
Issue: SPR-10534
Update ConfigurationClassUtils to only consider beans with @Bean
methods as 'lite' configuration candidates.
Prior to this commit all @Component beans were considered 'lite'
configuration candidates which could result in a large number of
ConfigurationClass instance being created that would ultimately be
ignored.
Issue: SPR-10609
Previously ConfigurationClassParser could override a nested
@Configuration without consideration of @Bean's defined in parent
classes.
This commit ensures that if the original ConfigurationClass contains
additional bean definitions it is processed again.
Issue: SPR-10546
(cherry picked from commit 940011e)
Refactor ConfigurationClassEnhancer so that BeanFactory instances are
not held against CGLIB Callback objects. Enhanced @Configuration classes
now use the BeanFactoryAware interface in order to obtain a BeanFactory.
This change has the additional benefit that a static final field can
now be used to hold all Callback instances.
Issue: SPR-10307
Introduce new @Conditional annotation that can be used to filter
which @Configuration classes or methods are loaded. @Conditional
can be used directly or as a meta-annotation. Condition implementations
are provided via the 'Condition' interface and are free to filter based
on any criteria available at the time that they run. The
ConditionalContext provides access to the BeanDefinitionRegistry,
Environment and ConfigurableListableBeanFactory along with a
ResourceLoader and ClassLoader.
The existing @Profile annotation has been refactored as a @Conditional
with the added benefit that it can now be used as a method level
annotation.
Add PropertySourcesPlaceholderConfigurer.getAppliedPropertySources() to
allow access to the PropertySources that were actually applied.
Issue: SPR-10545
Removed spring-beans.dtd (the 1.x variant) and spring-oxm-1.5.xsd (pre-Spring-Framework variant), in order to raise the backwards compatibility limit a little bit at least. We'll keep supporting the 2.0 and 2.5 xsd versions for the time being, as well as spring-beans-2.0.dtd.
Removed the ref 'local' attribute in spring-beans-4.0.xsd since 'local' lost its differentiating role to a regular bean ref back in the 3.1 days when we started allowing for the same bean id to reappear in a different beans section of the same configuration file (with a different profile).
Issue: SPR-10437
Allow classes that are annotated with @Import to be considered as 'lite'
@Configuration candidates. Allows the AnnotationConfigApplicationContext
to directly register @Import beans even if they are not @Components.
Issue: SPR-10533
Use LinkedHashMaps/Sets wherever exposed to users, and code tests defensively in terms of expected Map/Set ordering. Otherwise, there'll be runtime order differences between JDK 7 and JDK 8 due to internal HashMap/Set implementation differences.
Issue: SPR-9639
Juergen Hoeller
Sebastien Deleuze
Stephane Nicoll
Andy Clement
Sam Brannen
Mario Arias
Kazuki Shimizu
Philippe Marschall
spodgurskiy
Ruslan Sibgatullin
Johnny Lim
Phillip Webb
Tobias Montagna-Hay
Juergen Hoeller
Stephane Nicoll
Marten Deinum
Craig Andrews
Phillip Webb
Rossen Stoyanchev
Oliver Gierke
Phillip Webb
Rob Winch