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
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.
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
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.
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.
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.
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.
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.
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'.
Costin Leau
Chris Beams
Micha Kiener
Sam Brannen
Rossen Stoyanchev
Juergen Hoeller
Arjen Poutsma
Keith Donald
Ramnivas Laddad
Ben Hale
David Syer
Mark Fisher
Mark Pollack