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
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
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.
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
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, @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
Renamed TransactionManagementConfigurer#createTransactionManager()
to #annotationDrivenTransactionManager() to better reflect the fact
that the implemented method is optionally eligible for @Bean annotation.
See Javadoc for details.
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
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
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
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.
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
* 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
* Environment now extends PropertyResolver
* Environment no longer exposes resolver and sources
* PropertySource is String,Object instead of String,String
* PropertySource no longer assumes enumerability of property names
* Introduced EnumerablePropertySource for those that do have enumerable property names
Decomposed Environment interface into PropertySources, PropertyResolver
objects
Environment interface and implementations are still present, but
simpler.
PropertySources container aggregates PropertySource objects;
PropertyResolver provides search, conversion, placeholder
replacement. Single implementation for now is
PropertySourcesPlaceholderResolver
Renamed EnvironmentAwarePropertyPlaceholderConfigurer to
PropertySourcesPlaceholderConfigurer
<context:property-placeholder/> now registers PSPC by default, else
PPC if systemPropertiesMode* settings are involved
Refined configuration and behavior of default profiles
See Environment interface Javadoc for details
Added Portlet implementations of relevant interfaces:
* DefaultPortletEnvironment
* PortletConfigPropertySource, PortletContextPropertySource
* Integrated each appropriately throughout Portlet app contexts
Added protected 'createEnvironment()' method to AbstractApplicationContext
Subclasses can override at will to supply a custom Environment
implementation. In practice throughout the framework, this is how
Web- and Portlet-related ApplicationContexts override use of the
DefaultEnvironment and swap in DefaultWebEnvironment or
DefaultPortletEnvironment as appropriate.
Introduced "stub-and-replace" behavior for Servlet- and Portlet-based
PropertySource implementations
Allows for early registration and ordering of the stub, then
replacement with actual backing object at refresh() time.
Added AbstractApplicationContext.initPropertySources() method to
support stub-and-replace behavior. Called from within existing
prepareRefresh() method so as to avoid impact with
ApplicationContext implementations that copy and modify AAC's
refresh() method (e.g.: Spring DM).
Added methods to WebApplicationContextUtils and
PortletApplicationContextUtils to support stub-and-replace behavior
Added comprehensive Javadoc for all new or modified types and members
Added XSD documentation for all new or modified elements and attributes
Including nested <beans>, <beans profile="..."/>, and changes for
certain attributes type from xsd:IDREF to xsd:string
Improved fix for detecting non-file based Resources in
PropertiesLoaderSupport (SPR-7547, SPR-7552)
Technically unrelated to environment work, but grouped in with
this changeset for convenience.
Deprecated (removed) context:property-placeholder
'system-properties-mode' attribute from spring-context-3.1.xsd
Functionality is preserved for those using schemas up to and including
spring-context-3.0. For 3.1, system-properties-mode is no longer
supported as it conflicts with the idea of managing a set of property
sources within the context's Environment object. See Javadoc in
PropertyPlaceholderConfigurer, AbstractPropertyPlaceholderConfigurer
and PropertySourcesPlaceholderConfigurer for details.
Introduced CollectionUtils.toArray(Enumeration<E>, A[])
Work items remaining for 3.1 M2:
Consider repackaging PropertySource* types; eliminate internal use
of SystemPropertyUtils and deprecate
Further work on composition of Environment interface; consider
repurposing existing PlaceholderResolver interface to obviate need
for resolve[Required]Placeholder() methods currently in Environment.
Ensure configurability of placeholder prefix, suffix, and value
separator when working against an AbstractPropertyResolver
Add JNDI-based Environment / PropertySource implementatinos
Consider support for @Profile at the @Bean level
Provide consistent logging for the entire property resolution
lifecycle; consider issuing all such messages against a dedicated
logger with a single category.
Add reference documentation to cover the featureset.
Spring Buildmaster
Chris Beams
Sam Brannen
Juergen Hoeller
Keith Donald