Prior to this change, a @Configuration classes that @ComponentScan
themselves would result in a ConflictingBeanDefinitionException.
For example:
package com.foo.config;
@Configuration
@ComponentScan("com.foo");
public class AppConfig {
// ...
}
This resulted in a ConflictingBeanDefinitionException that users have
typically worked around in the following fashion:
package com.foo.config;
@Configuration
@ComponentScan(basePackages="com.foo",
excludeFilters=@Filter(value=ANNOTATION_TYPE, type=Configuration.class);
public class AppConfig {
// ...
}
This is obviously more verbose and cumbersome than would be desirable,
and furthermore potentially too constraining as it prohibits the ability
to include other legitimate @Configuration classes via scanning.
The exception was being thrown because of a logic problem in
ClassPathBeanDefinitionScanner. The bean definition for AppConfig gets
registered once by the user (e.g. when constructing an
AnnotationConfigApplicationContext), then again when performing the
component scan for 'com.foo'. Prior to this change,
ClassPathBeanDefinitionScanner's #isCompatible returned false if the new
bean definition was anything other than an AnnotatedBeanDefinition. The
intention of this check is really to see whether the new bean definition
is a *scanned* bean definition, i.e. the result of a component-scanning
operation. If so, then it becomes safe to assume that the original bean
definition is the one that should be kept, as it is the one explicitly
registered by the user.
Therefore, the fix is as simple as narrowing the instanceof check from
AnnotatedBeanDefinition to its ScannedGenericBeanDefinition subtype.
Note that this commit partially reverts changes introduced in SPR-8307
that explicitly caught ConflictingBeanDefinitionExceptions when
processing recursive @ComponentScan definitions, and rethrew as a
"CircularComponentScanException. With the changes in this commit,
such CBDEs will no longer occur, obviating the need for this check and
for this custom exception type altogether.
Issue: SPR-8808, SPR-8307
The AbstractHttpMessageConverter was using the requested Content-Type
rather than the actual response Content-Type to determine the length
of the content. This can lead to a problem when a controller returns
a ResponseEntity with a Content-Type header that ignores (overrides)
the requested Content-Type. The fix ensures that actual response
Content-Type is the one used both to write to the response and to
determine the length of the content.
Equivalent to <context:spring-configured/>.
Also update @EnableLoadTimeWeaving Javadoc and spring-configured XSD
documentation to reflect.
Issue: SPR-7888
3.1 M2 introduced a regression that causes false positives during
@Configuration class candidate checks. Now performing a call to
AnnotationMetadata#isInterface in addition to checks for @Component and
@Bean annotations when determining whether a candidate is a 'lite'
configuration class. Annotations are in the end interfaces, so both
are filtered out at once.
Issue: SPR-8761
Prior to this change, any instantiation of an
AnnotationConfigApplicationContext would trigger the creation of three
StandardEnvironment objects: one for the ApplicationContext, one for the
AnnotatedBeanDefinitionReader, and one for the
ClassPathBeanDefinitionScanner.
The latter two are immediately swapped out when the ApplicationContext
delegates its environment to these subordinate objects anyway. Not only
is it inefficient to create these two extra Environments, it creates
confusion when debug-level logging is turned on. From the user's
perspective and in practice, there is only one Environment; logging
should reflect that.
This change ensures that only one Environment object is ever created for
a given ApplicationContext. If an AnnotatedBeanDefinitionReader or
ClassPathBeanDefinitionScanner are used in isolation, e.g. against a
plain BeanFactory/BeanDefinitionRegistry, then they will still create
their own local StandardEnvironment object.
All public API compatibility is preserved; new constructors have been
added where necessary to accommodate passing an Environment directly
to ABDR ar CPBDS.
Properties such as 'spring.profiles.active' cannot be specified at the
command line under Bash and other shells due to variable naming
constraints. This change allows for exchanging underscores for periods
as well as capitalizing property names for more idiomatic naming when
dealing with environment variables.
For example, Spring will respect equally either of the following:
spring.profiles.active=p1 java -classpath ... MyApp
SPRING_PROFILES_ACTIVE=p1 java -classpath ... MyApp
The former is not possible under Bash, while the latter is. No code or
configuration changes are required; SystemEnvironmentPropertySource
adapts for these varations automatically.
SystemEnvironmentPropertySource is added by default as
"systemEnvironment" to StandardEnvironment and all subtypes, taking the
place of the plain MapPropertySource that was in use before this change.
Issue: SPR-8869
Allowing beans of primitive type to be looked up via getBean(Class), or
to be injected using @Autowired or @Injected or @Resource. Prior to
these changes, an attempt to lookup or inject a bean of, for example,
type boolean would fail because all spring beans are Objects, regardless
of initial type due to the way that ObjectFactory works.
Now these attempts to lookup or inject primitive types work, thanks to
simple changes in AbstractBeanFactory using ClassUtils#isAssignable
methods instead of the built-in Class#isAssignableFrom. The former takes
into account primitives and their object wrapper types, whereas the
latter does not.
The need to declare, look up or inject primitive-typed beans is probably
low -- how often does one need a bean of type boolean or int after all?.
Prior to the introduction of @Bean methods in Spring 3.0, it was not
possible in practice to register primitive beans, so this issue never
came up. Now that one can declare primitive-typed beans, it does make
sense that we properly support by-type lookup and injection without
forcing the user to work with object wrappers.
Issue: SPR-8874
Currently the combine method consolidates "/*" and "/hotel"
into "/hotel". However if the first pattern contains URI template
variables, the consolidation seems wrong. The fix is to prevent
the consolidation if the first pattern contains "{".
Certain edge cases around return type covariance can trigger an
IntrospectionException when trying to create a new PropertyDescriptor;
particularly around the addition of write methods with parameter types
that do not match read method return types.
These type mismatch exceptions are raised during normal Introspector
operations as well (i.e. without ExtendedBeanInfo in the mix), but
the Introspector intentionally supresses them. In covariance cases,
there is often already a suitable write method present, e.g. discovered
in a supertype or superinterface, that, with the benefit of bridge
methods works just fine in practice at runtime. That is to say, in
these suppression cases, the rejection of the write method is 'OK' in
that there is already a write method present that can handle a call.
ExtendedBeanInfo now mirrors this suppression behavior, but does issue
a WARN-level log message to let the user know.
An important effect of this change is that ExtendedBeanInfo now modifies
the delegate BeanInfo object, whereas previously it did not. In practice
this probably matters very little, but it is a design change worth
noting. The reason for this change was to avoid the need to create new
PropertyDescriptors wherever possible. It was discovered that by updating
existing PDs, one can avoid these IntrospectionExceptions a greater
percentage of the time.
Issue: SPR-8806
The UriComponentsBuilder instance passed into the method is initialized
with current request information including host, scheme, port, context
path, and the servlet mapping's literal part.
Also added shortcut methods to buildAndExpand in UriComponentsBuilder.
The registration of more than one ConfigurationClassPostProcessor
results in the double-enhancement of @Configuration classes, i.e. a
two-deep CGLIB subclass hierarchy is created.
As a side-effect of changes introduced in 3.1 M2 fixing SPR-8080, this
behavior now results in an infinite loop at CGLIB callback processing
time, leading to a StackOverflowException which is then suppressed by
the container, and ultimately results in the user being presented with
an unintuitive "Bean 'x' is not already in creation" exception.
This fix introduces a marker interface 'EnhancedConfiguration' to be
implemented by all generated @Configuration subclasses. The
configuration class enhancer can then behave in an idempotent fashion
by checking to see whether a candidate @Configuration class is already
assignable to this type i.e. already enhanced and ignore it if so.
Naturally, users should avoid registering more than one
ConfigurationClassPostProcessor, but this is not always possible. As
with the case in point, SPR-8824 originates from problems with
spring-data-neo4j, which explicitly registers its own
ConfigurationClassPostProcessor. The user has little control over this
arrangement, so it is important that the framework is defensive as
described above.
Issue: SPR-8824
The initial solution kept these three in full sync at all times:
contentType field, characterEncoding field, 'Content-Type' header.
That is correct behavior, however it breaks existing tests that rely
on contentType and characterEncoding being equal to exactly what
they were set to.
For example, consider:
response.setContentType("text/plain");
response.setCharacterEncoding("UTF-8");
Ideally both contentType and the 'Content-Type' header would now be
"text/plain;charset=UTF-8". However, existing tests would expect
that contentType is equal to "text/plain".
To avoid breaking existing tests, contentType and characterEncoding
will continue to be equal to exactly what they were set to while
the 'Content-Type' header will always include both the content
type and the charset.
The only exception to this rule is when a 'Content-Type' header
is set explicitly, the contentType and characterEncoding fields will
be updated accordingly, possibly overriding the existing values.
The Content-Type header and the contentType field in HttpServletRequest/Response
are now always in sync. When a header is added the contentType field is updated
as well and vice versa.
Similarly when the Content-Type header or the contentType field includes a charset
field, the character encoding is updated and vice versa.
Separate concerns of @Configuration class selection from the need to
register certain infrastructure beans such as auto proxy creators.
Prior to this change, ImportSelector implementations were responsible
for both of these concerns, leading to awkwardness and duplication.
Also introduced in this change is ImportBeanDefinitionRegistrar and
two implementations, AutoProxyRegistrar and AspectJAutoProxyRegistrar.
See the refactored implementations of CachingConfigurationSelector,
TransactionManagementConfigurationSelector to see the former;
AspectJAutoProxyConfigurationSelector to see the latter.
ImportSelector and ImportBeanDefinitionRegistrar are both handled as
special-case arguments to the @Import annotation within
ConfigurationClassParser.
These refactorings are important because they ensure that Spring users
will be able to understand and extend existing @Enable* annotations
and their backing ImportSelector and @Configuration classes, as well
as create their own with a minimum of effort.
Also eliminate all 'cache definition' language in favor of
'cache operation' in comments, method and parameter names (most
classes had already been refactored to this effect).
Unfortunately creates a large diff due to whitespace changes as well as
false attribution of authorship from a git/svn 'blame' perspective.
Be sure to perform diffs using `git diff -w` or `svn diff -w` when
reviewing recent changes to these sources to ignore all whitespace.
In favor of existing #setCacheOperationSources(CacheOperationSource...)
Also polish Javadoc throughout, replacing stale references to
CacheDefinitionSource where appropriate as well as other minor changes
Facilitates type-safe programmatic configuration from @Bean methods:
@Bean
public CacheManager cacheManager() {
SimpleCacheManager cm = new SimpleCacheManager();
cm.setCaches(Arrays.asList(
new ConcurrentMapCache("default"),
new ConcurrentMapCache("primary"),
new ConcurrentMapCache("secondary")
));
return cm;
}
Prior to this change, the code above would have raised errors on the
Arrays.asList() call because it returns a Collection<? extends Cache>
as opposed to Collection<Cache>.
After this change, AbstractCacheManager expects
Collection<? extends Cache> throughout.
This was removed once previously but accidentally re-introduced later.
The 'correct' version of spring-cache-3.1.xsd lives in spring-context
as opposed to here in spring-context-support.
Also placed .gitignore file within src/main/resources such that the
now-empty directory does not get pruned in git environments, which will
otherwise cause 'missing source folder' errors within Eclipse/IDEA.
Refactored getConfig => getApplicationContext such that subclasses have
control over the type of ApplicationContext used by the base class
tests. Done in anticipation of @EnableCaching tests that will favor use
of AnnotationConfigApplicationContext
Also updated all use of ClassPathXmlApplictionContext to
GenericXmlApplicationContext, which is generally preferred.
There was some question about whether enabling subclass proxies via
proxyTargetClass / proxy-target-class settings would break annotation-
based demarcation of joinpoints due to inability to discover those
annotations in various scenarios. The provided tests prove that in
any conceivable case, these annotations (@Transactional, at least)
are discovered in a consistent fashion, meaning that switching proxy
strategies should be transparent to the application and honor
intended annotation semantics.
Since dynamic attributes were allowed in Spring 3, it raised the
possibility to specify a type attribute on a number of the form tags.
Where it makes sense (see below) that attribute is now rejected
and reversely where it makes sense it is accepted.
InputTag allows types other than "text" but rejects type="radio" or
type="checkbox" since there is a good reason for those to be used
only in conjunction with the appropriate form library tags.
Other HTML input tags such as PasswordTag, HiddenInputTag,
Checkbox(es)Tag and RadioBox(es)Tag check the dynamic attributes
and reject them if they contain a type attribute since.
Anywhere the value of a destroy method may be expressed, specifying
the value "(inferred)" now indicates that the container should attempt
to automatically discover a destroy method. This functionality is
currently limited to detecting public, no-arg methods named 'close';
this is particularly useful for commonly used types such as Hibernate
SessionFactory most JDBC DataSource implementations, JMS connection
factories, and so forth.
This special value is captured as the constant
AbstractBeanDefinition#INFER_METHOD, which in turn serves as the default
value of the @Bean#destroyMethod attribute.
For example in the following case
@Bean
public BasicDataSource dataSource() { ... }
the container will automatically detect BasicDataSource#close and invoke
it when the enclosing ApplicationContext is closed. This is exactly
equivalent to
@Bean(destroyMethod="(inferred)")
public BasicDataSource dataSource() { ... }
A user may override this inference-by-default convention simply by
specifying a different method
@Bean(destroyMethod="myClose")
public MyBasicDataSource dataSource() { ... }
or, in the case of a bean that has an otherwise inferrable 'close'
method, but the user wishes to disable handling it entirely, an empty
string may be specified
@Bean(destroyMethod="")
public MyBasicDataSource dataSource() { ... }
The special destroy method name "(inferred)" may also be specified in
an XML context, e.g.
<bean destroy-method="(inferred)">
or
<beans default-destroy-method="(inferred)">
Note that "(inferred)" is the default value for @Bean#destroyMethod,
but NOT for the destroy-method and default-destroy-method attributes
in the spring-beans XML schema.
The principal reason for introducing this feature is to avoid forcing
@Configuration class users to type destroyMethod="close" every time a
closeable bean is configured. This kind of boilerplate is easily
forgotten, and this simple convention means the right thing is done
by default, while allowing the user full control over customization or
disablement in special cases.
Issue: SPR-8751
Use of package private @Bean methods can cause issues if the class
is extended and the sub-class is in a different package. This is
covered in detail in SPR-8756.
Certain external javadoc links were broken or out of date, namely
Hibernate, Java SE and EE 6, Quartz, and Apache Pluto. All resolve
properly now.
Issue: SPR-8720
Add BridgeMethodResolver#isJava6VisibilityBridgeMethodPair to
distinguish between (a) bridge methods introduced in Java 6 to
compensate for inheriting public methods from non-public superclasses
and (b) bridge methods that have existed since Java 5 to accommodate
return type covariance and generic parameters.
In the former case, annotations should be looked up from the original
bridged method (SPR-7900). In the latter, the annotation should be
looked up against the bridge method itself (SPR-8660).
As noted in the Javadoc for the new method, see
http://stas-blogspot.blogspot.com/2010/03/java-bridge-methods-explained.html
for a useful description of the various types of bridge methods, as
well as http://bugs.sun.com/view_bug.do?bug_id=6342411, the bug fixed in
Java 6 resulting in the introduction of 'visibility bridge methods'.
Issue: SPR-8660, SPR-7900
Remove all convenience variants of #findAllAnnotationAttributes and
refactor the remaining method to accept a MetadataReaderFactory
instead of creating its own SimpleMetadataReaderFactory internally.
This allows clients to use non-default class loaders as well as
customize the particular MetadataReaderFactory to be used (e.g.
'simple' vs 'caching', etc).
Issue: SPR-8752
This commit and the several before it back out the
SessionFactoryBuilder and AnnotationSessionFactoryBuilder types
recently introduced in 3.1 M2. This is in light of the impending
release of Hibernate 4.0 GA and our own support for it the new
org.springframework.orm.hibernate4 package (not yet committed).
This new package will have a similar, but far simpler, arrangement of
a single LocalSessionFactoryBuilder and LocalSessionFactoryBean pair.
Hibernate 3.x support will remain largely as-is, however the
HibernateTransactionManager introduced with SPR-8076 will remain.
This reverts commit 9e8259198f.
Issue: SPR-8066, SPR-7936, SPR-8076, SPR-8098, SPR-8096, SPR-7387
Removed formal deprecation warnings for AbstractSingletonFactoryBean and
its TransactionProxyFactoryBean and CacheProxyFactoryBean subclasses.
This is principally because TPFB is still used by Grails and could
conceivably be used to good effect by any third-party framework in a
similar fashion. CPFB is new with 3.1, but similar use is predictable.
Deprecations have been replaced by strong recommendations that users
avoid these types in modern Spring applications and favor the use of
namespaces and annotatinos, such as tx: and @Transactional (around
since Spring 2.x) and cache: and @Cacheable.
Issue: SPR-8680, SPR-8686
In anticipation of 'destroy method inference' feature, introduce
ConfigurationClassUtils#INFER_METHOD and update @Bean#destroyMethod to
reflect its use.
Issue: SPR-8751
When a @ModelAttribute is instantiated from a URI variable with type
conversion, if conversion fails allow the exception to propagate.
This is consistent with what happens on type conversion failure with
@PathVariable and other args that rely on type conversion.
Make it possible to hook in custom ServletRequestDataBinderFactory
by overriding RequestMappingHandlerAdapter.
Create ExtendedServletRequestDataBinder to add URI template vars
to the binding values taking advantage of a new extension hook in
ServletRequestDataBinder to provide additional values to bind.
RequestCondition types keep individual expression types (e.g. the
discrete header or param expressions) package private. Although the
implementation of these types should remain private, there is no
reason not to provide access to the underlying expression data --
e.g. for creating a REST endpoint documentation tool, or if you
want to know which of the "consumes"/"produces" media types
are negated.
This change ensures that all RequestCondition types have a public
getter that makes available the basic expression data.
1. Consider single-purpose return value types like HttpEntity, Model,
View, and ModelAndView ahead of annotations like @ResponseBody and
@ModelAttribute. And reversely consider multi-purpose return value
types like Map, String, and void only after annotations like
@RB and @MA.
2. Order custom argument resolvers and return value handlers after the
built-in ones also clarifying the fact they cannot be used to override
the built-in ones in Javadoc throughout.
3. Provide hooks in RequestMappingHandlerAdapter that subclasses can use
to programmatically modify the list of argument resolvers and return
value handlers, also adding new getters so subclasses can get access
to what they need for the override.
4. Make SessionStatus available through ModelAndViewContainer and
provide an argument resolver for it.
5. Init test and javadoc improvements.
Previously, #containsBean Javadoc advertised that a true return value
indicates that a call to #getBean for the same name would succeed.
This is actually not the case, and has never been. The semantics
of #containsBean have always been to indicate whether a bean definition
with the given name is definied or a singleton instance with the given
name has been registered.
The Javadoc now reflects this accurately.
Issue: SPR-8690
Cite original inspiriation by Domain-Driven Design, but make clear the
flexible and general-purpose nature of Spring's stereotype annotations
such as @Repository and @Service.
Also update @Repository Javadoc with more explicit instructions about
switching on exception translation through use of
PersistenceExceptionTranslationPostProcessor, and update PETPP Javadoc
for style as well as concrete examples of 'resource factories' that
implement the PersistenceExceptionTranslator interface
Issue: SPR-8691
When set to 'true' the flag makes RedirectAttributes the only way to add
attributes for a redirect thus ignoring the content of the default model
even if RedirectAttributes is not in the list of controller method args.
Commit http://bit.ly/nXumTs ensured that component methods and fields
marked with 'common annotations' such as @Resource, @PostConstruct and
@PreDestroy are invoked/assigned once and only once, even if multiple
instances of the CommonAnnotationBeanPostProcessor are processing the
same bean factory.
The implementation works against the InjectionMetadata API, adding and
removing these members from sets that track whether they are already
'externally managed', i.e. that another CABPP has already handled them,
thus avoiding redundant processing.
Prior to this change, the #remove operations against these sets were
not synchronized. In a single-threaded context this is fine thanks to
logic in AbstractAutowireCapableBeanFactory#doCreateBean that checks to
see whether a given bean definition has already been post processed.
However, as reported by SPR-8598, certain cases involving multiple
threads and annotated prototype-scoped beans can cause concurrent
modification exceptions during the #remove operation (ostensibly because
another thread is attempting to do the same removal at the same time,
though this has yet to be reproduced in isolation).
Now the sets originally introduced by the commit above are decorated
with Collections#synchronizedSet and any iterations over those sets
are synchronized properly. This change should have low performance
impact as such processing happens at container startup time (save for
non-singleton lookups at runtime), and there should be little
contention in any case.
Issue: SPR-8598
Separate client from server errors as much as possible in this order:
- raise MultipartException when resolving a multipart arg and the
request is not a multipart request (400)
- raise IllegalArgumentException when the arg type is MultipartFile
but the request is not of type MultipartHttpServletRequest (500)
- raise MissingServletRequestPartException when a MultipartResolver
is in use but the part is not found (400)
- detect presence of Servlet 3.0 before using standard multipart
parsing to find a request part or raise
IllegalArgumentException (500)
Unfortunately it is not always possible to separate client from
server errors mainly because the Servlet 3.0 API does not
distinguish between the case of 0 request parts vs multipart
processing not being configured.
Prior to this change, spring-orm/template.mf was exclusive of javax.jdo
3.0.0. Now, after local testing against the newly-released jdo-api 3.0
jar, the template has been updated to allow for use in OSGi containers.
Note that actually updating build dependency descriptors to JDO 3.0 such
that the framework is continually tested against this version is covered
by a separate issue (SPR-8668).
Issue: SPR-8667, SPR-8655
Prior to this change, StandardServletEnvironment evaluated a
"jndiPropertySourceEnabled" flag to determine whether or not to add a
JndiPropertySource. Following the changes introduced in SPR-8490, there
is now no reason not to enable a JNDI property source by default. This
change eliminates the support for "jndiPropertySourceEnabled" and adds
a JndiPropertySource automatically.
Issue: SPR-8545, SPR-8490
Provides a convenient mechanism for activating an additional profile
while preserving those that are already active, as opposed to
calling #setActiveProfiles with the contents of #getActiveProfiles plus
the new profile.
Issue: SPR-8548
- Removed generatesDefaults() and supports() from the SmartContextLoader SPI and modified the DelegatingSmartContextLoader algorithm accordingly.
- DelegatingSmartContextLoader no longer operates on a list of candidate loaders but rather on explicit instances of GenericXmlContextLoader and AnnotationConfigContextLoader.
- Updated Javadoc regarding DelegatingSmartContextLoader as the new default loader.
- Updated and polished Javadoc regarding changes in 3.1.
- Now enforcing @ContextConfiguration's restriction on declaring locations or classes but not both.
SessionFactory proxies created by (Annotation)SessionFactoryBuilder now
implement InfrastructureProxy to ensure they are automatically unwrapped
for transaction resource management purposes.
Issue: SPR-8492
Prior to this change, a parsing exception would be thrown if a
<description> element was placed within a <map><entry/></map>
element. The beans XSD has always permitted this arrangement,
but BeanDefinitionParserDelegate did not respect it. The latter now
simply ignores any <description> element, rather than failing.
Issue: SPR-8563
A <scheduled:task> element declared within a
<beans default-lazy-init="true"> element represents a contradiction in
terms: such a task will never be executed.
For this reason, we now override any inherited lazy-init settings
when parsing <scheduled:task> elements, forcing lazy-init to false
for the underlying ScheduledTaskRegistrar bean.
Thanks to Mike Youngstrom for contributing an initial patch.
Issue: SPR-8498
This change returns the invocation order of
ConfigurationClassPostProcessor#enhanceConfigurationClasses to its
pre-3.1 M2 state. An earlier (and now unnecessary) refactoring in
service of @Feature method processing caused the change that this now
reverts.
Prior to this change, an instance of ConfigurationClassPostProcessor
would throw IllegalStateException if its
postProcessBeanDefinitionRegistry method were called more than once.
This check is important to ensure that @Configuration classes are
not proxied by CGLIB multiple times, and works for most normal use
cases.
However, if the same CCPP instance is used to process multiple
registries/factories/contexts, this check creates a false negative
because it does not distinguish between invocations of
postProcessBeanDefinitionRegistry across different registries.
A use case for this, though admittedly uncommon, would be creating
a CCPP instance and registering it via
ConfigurableApplicationContext#addBeanDefinitionPostProcessor against
several ApplicationContexts. In such a case, the same CCPP instance
will post-process multiple different registry instances, and throw the
above mentioned exception.
With this change, CCPP now performs lightweight tracking of the
registries/beanFactories that it has already processed by recording
the identity hashcodes of these objects. This is only slightly more
complex than the previous boolean-based 'already processed' flags, and
prevents this issue (however rare it may be) from occurring.
Issue: SPR-8527
<emphasis role="bold"> blocks do not render properly, probably due to
conflicting CSS used for syntax highlighting. For the moment, any
mentions of bold text (e.g. "see bold text in the snippet below") have
been removed to avoid confusion as reported in SPR-8520. SPR-8526 has
been created to address the underlying issue of getting bold to work
even with syntax highlighting.
Issue: SPR-8520, SPR-8526
Prior to this change, @EnableTransactionManagement (via the
ProxyTransactionManagementConfiguration class) did not properly
register its auto-proxy creator through the usual AopConfigUtils
methods. It was trying to register the APC as a normal @Bean method,
but this causes issues (SPR-8494) with the logic in
AopConfigUtils#registerOrEscalateApcAsRequired, which expects the APC
bean definition to have a beanClassName property. When the APC is
registered via a @Bean definition, it is actually a
factoryBean/factoryMethod situation with no directly resolvable
beanClass/beanClassName.
To solve this problem, ImportSelector#selectImports has been refactored
to accept an ImportSelector.Context instance. This object contains the
AnnotationMetadata of the importing class as well as the enclosing
BeanDefinitionRegistry to allow for the kind of conditional bean
registration necessary here. In this case, the bean definition that
must be registered conditionally is that of the auto-proxy creator.
It should only be registered if AdviceMode == PROXY, and thus the
ImportSelector is an appropriate place to make this happen. It must
happen as a BeanDefinition (rather than a @Bean method) for
compatibility with AopConfigUtils, and working with the
BeanDefinitionRegistry API allows for that. This change does mean that
in certain cases like this one, #selectImports has container modifying
side effects. Documentation has been updated to reflect.
Issue: SPR-8411, SPR-8494
@PostConstruct added to ProxyTransactionManagementConfiguration cases
ConcurrentModificationException (as detailed previously in SPR-8397.
Backing out for now until a better solution can be devised.
This reverts commit 235b729514.
Prior to this change, @EnableTransactionManagement (via the
ProxyTransactionManagementConfiguration class) did not properly
register its auto-proxy creator through the usual AopConfigUtils
methods. It was trying to register the APC as a normal @Bean method,
but this causes issues (SPR-8494) with the logic in
AopConfigUtils#registerOrEscalateApcAsRequired, which expects the APC
bean definition to have a beanClassName property. When the APC is
registered via a @Bean definition, it is actually a
factoryBean/factoryMethod situation with no directly resolvable
beanClass/beanClassName.
Rather than trying to rework how AopConfigUtils works, a @PostConstruct
method has been added to ProxyTransactionManagementConfiguration to call
the usual AopConfigUtils registration methods.
Issue: SPR-8411, SPR-8494
SessionFactoryBuilderSupport implementations create DisposableBean
proxies for SessionFactory objects created using #buildSessionFactory.
Prior to this change, these proxies create problems when working agaist
SessionFactoryUtils.getDataSource(SessionFactory), because this method
expects the given SessionFactory to implement Hibernate's
SessionFactoryImplementor interface (which the stock SessionFactoryImpl
does).
With this change, the DisposableBean proxies created by SFBuilders
now also implement SessionFactoryImplementor to satisfy this and
probably other such cases.
Issue: SPR-8469
For the particular use case detailed in SPR-8514, with this change we
now attempt to determine the object type of a FactoryBean through its
generic type parameter if possible.
For (a contrived) example:
@Configuration
public MyConfig {
@Bean
public FactoryBean<String> fb() {
return new StringFactoryBean("foo");
}
}
The implementation will now look at the <String> generic parameter
instead of attempting to instantiate the FactoryBean in order to call
its #getObjectType() method.
This is important in order to avoid the autowiring lifecycle issues
detailed in SPR-8514. For example, prior to this change, the following
code would fail:
@Configuration
public MyConfig {
@Autowired Foo foo;
@Bean
public FactoryBean<String> fb() {
Assert.notNull(foo);
return new StringFactoryBean("foo");
}
}
The reason for this failure is that in order to perform autowiring,
the container must first determine the object type of all configured
FactoryBeans. Clearly a chicken-and-egg issue, now fixed by this
change.
And lest this be thought of as an obscure bug, keep in mind the use case
of our own JPA support: in order to configure and return a
LocalContainerEntityManagerFactoryBean from a @Bean method, one will
need access to a DataSource, etc -- resources that are likely to
be @Autowired across @Configuration classes for modularity purposes.
Note that while the examples above feature methods with return
types dealing directly with the FactoryBean interface, of course
the implementation deals with subclasses/subinterfaces of FactoryBean
equally as well. See ConfigurationWithFactoryBeanAndAutowiringTests
for complete examples.
There is at least a slight risk here, in that the signature of a
FactoryBean-returing @Bean method may advertise a generic type for the
FactoryBean less specific than the actual object returned (or than
advertised by #getObjectType for that matter). This could mean that an
autowiring target may be missed, that we end up with a kind of
autowiring 'false negative' where FactoryBeans are concerned. This is
probably a less common scenario than the need to work with an autowired
field within a FactoryBean-returning @Bean method, and also has a clear
workaround of making the generic return type more specific.
Issue: SPR-8514
isCglibProxy* methods in AopUtils are useful in lower-level modules,
i.e. those that cannot depend on .aop. Therefore copied these methods
to ClassUtils; deprecated the existing ones in AopUtils and now
delegating to the new location; switched all usage of
AopUtils#isCglibProxy* within the framework to use
ClassUtils#isCglibProxy* instead.
Even after applying @Ignore to these tests at the class level, they
still run (and fail) under ant when the jmxremote_optional jar is not
present. See the issues mentioned below for information on how these
tests will be re-enabled.
Issue: SPR-8089, SPR-8093, SPR-8458
Prior to this change, (Context)SingletonBeanFactoryLocator used
BeanFactoryUtils#beanOfType(ListableBeanFactory, Class) to locate the
bean of type BeanFactory.
The more modern approach is to use BeanFactory#getBean(Class), which
removes a dependency on ListableBeanFactory interface while at the same
time opening the implementation up to respecting autowiring exclusions,
primary metadata, etc.
Issue: SPR-8489
For consistency with all other constants representing default
property source names, such as
StandardServletEnvironment#SERVLET_CONTEXT_PROPERTY_SOURCE_NAME and
StandardEnvironment#SYSTEM_ENVIRONMENT_PROPERTY_SOURCE_NAME
Issue: SPR-8482
Prior to this change, JndiPropertySource worked directly against a JNDI
Context instance as its 'source' object. This works well enough, but is
not nearly as fully-featured as Spring's existing JndiLocatorDelegate.
This change refactors JndiPropertySource from relying on an underlying
Context to relying on an underlying JndiLocatorDelegate. By default,
the delegate's "resourceRef" property is set to true, meaning that the
implementation will always try to prepand a given name with
"java:comp/env/" before looking up the name, and upon failure will drop
back to the given name sans prefix.
See JndiPropertySource Javadoc for complete details.
Issue: SPR-8490
Move JNDI_PROPERTY_SOURCE_ENABLED_FLAG from JndiPropertySource to
StandardServletEnvironment, as this is the only context in which the
constant makes sense.
Users may now work with command line arguments as a source of
properties for use with the PropertySource and Environment APIs.
An implementation based on the jopt library and a "simple"
implementation requiring no external libraries are are provided
out-of-the box.
See Javadoc for CommandLinePropertySource, JOptCommandLinePropertySource
and SimpleCommandLinePropertySource for details.
Issue: SPR-8482
Prior to this change, @Autowired injection against an instance of a
subclass having different visibility than its superclass would fail
if the @Autowired method is declared only in the superclass. This is due
to an apparent change in the rules around bridge method generation
between Java 5 and Java 6, and possibly even varying across compiler
vendors.
Now, BridgeMethodResolver is used consistently when detecting
@Autowired, @Inject and @Resource metadata to bypass these bridge
methods if they exist.
Issue: SPR-7900
- introduced processContextConfigurationAttributes() method in SmartContextLoader SPI
- refactored AnnotationConfigContextLoader, AbstractContextLoader, AbstractGenericContextLoader, ContextLoaderUtils, and TestContext implementations to take advantage of the SmartContextLoader SPI, MergedContextConfiguration, and ContextConfigurationAttributes
- deleted ResourceTypeAwareContextLoader
- deleted ContextLoaderUtils.LocationsResolver and implementations
- moved context key generation from TestContext to MergedContextConfiguration
Prior to this change, AbstractAutowireCapableBeanFactory did not support
a default ParameterNameDiscoverer. This meant that attempting to use
<constructor-arg name=".."> syntax would fail (with a fairly obscure
exception) as that feature depends on a ParameterNameDiscoverer to
introspect the constructor arguments.
This lack of a default was originally intended to avoid a dependency on
ASM, but now that (a) .asm is a built-in module and (b) .beans has a
non-optional compile-time dependency on .asm, there is no reason not to
provide this default.
The net effect is that in a number of locations throughout the
framework, namely in GenericApplicationContext and
AbstractRefreshableApplicationContext, it is no longer necessary to
explicitly call AACBF#setParameterNameDiscoverer. This also means that
using a naked BeanFactory (likely for testing scenarios) is that much
easier.
Issue: SPR-8184
Prior to this change, the Property class introduced in 3.1 M2 validated
read/write property method pairs based on whether their parameter/return
types were equal to one another. This precluded the valid possibility
of read method that returns a subtype of the write method's parameter
type, and represented a regression against 3.1 M1 and earlier versions.
The implementation now uses isAssignableFrom rather than a straight
equals check against the types.
Issue: SPR-8432
As of SPR-8093, jmxremote_optional.jar is present on the build
server in jre/lib/ext, but it is not by default present on local
developer / user machines, meaning that the build ends up broken
by default.
Issue: SPR-8089, SPR-8093, SPR-8458
Prior to this change, DirectFieldAccessor would ignore fields shadowed
in subclasses, favoring the last field processed, which happens to be
the most super declaration based on the way ReflectionUtils.doWithFields
works.
Because the locally shadowed field may be of a different type that the
superclass declaration, it is most correct to preserve and work with
the shadowed field.
Issue: SPR-8398
- TextContext now works with MergedContextConfiguration instead of locations and loader
- TextContext now builds context caching key from MergedContextConfiguration
- Test context caching is now based on locations, classes, active profiles, and context loader
- TextContext now delegates to SmartContextLoader or ContextLoader as appropriate
- AbstractContextLoader now implements SmartContextLoader
- AbstractGenericContextLoader now sets active profiles in the GenericApplicationContext
- Introduced integration tests for profile support in the TCF for both XML and annotation config
Renamed TransactionManagementConfigurer#createTransactionManager()
to #annotationDrivenTransactionManager() to better reflect the fact
that the implemented method is optionally eligible for @Bean annotation.
See Javadoc for details.
+ remove generic signature on key generator (as the type is not used anywhere)
+ add a small improvement to CacheAspect to nicely handle the cases where the aspect is pulled in but not configured
Consolidates ConversionService and ConverterRegistry interfaces;
implemented by GenericConversionService.
ConfigurablePropertyResolver#getConversionService now returns this
new type (hence so too does
ConfigurableEnvironment#getConversionService). This allows for
convenient addition / removal of Converter instances from Environment's
existing ConversionService. For example:
ConfigurableApplicationContext ctx = new ...
ConfigurableEnvironment env = ctx.getEnvironment();
env.getConversionService().addConverter(new FooConverter());
Issue: SPR-8389
This reverts commit da914bcfb4 and also
removes the use of Ordered#NOT_ORDERED from EnableTransactionManagement
and ProxyTransactionManagementConfiguration in favor of defaulting to
Ordered#LOWEST_PRIORITY, which is actually the default that results
when no 'order' attribute is specified in XML.
Attempt to access and modify the system environment works on OS X /
Linux but not under Windows. Does not represent any real failure for
production code - the need to modify the system environment is a
testing concern only, and one we can probably live without, considering
the losing battle necessary to make such a hack cross-platform.
Issue: SPR-8245
Constructors have been added to both ContextLoader and
ContextLoaderListener to support instance-based programmatic
registration of listeners within ServletContainerInitializer
implementations in Servlet 3.0+ environments, and more particularly
when using Spring 3.1's WebApplicationInitializer SPI.
Issue: SPR-7672
ContextLoader and FrameworkServlet now use
AnnotationAwareOrderComparator to support @Order usage; previously
supported only implementation of the Ordered interface.
Constructors have been added to both FrameworkServlet and
DispatcherServlet to support instance-based programmatic registration
of Servlets within ServletContainerInitializer implementations in
Servlet 3.0+ environments, and more particularly when using Spring 3.1's
WebApplicationInitializer SPI.
This change also renames the method added to FrameworkServlet in
SPR-8185 from #initializeWebApplicationContext to #applyInitializers.
The reason being that a method named #initWebApplicationContext was
already present and the names overlapped confusingly.
Issue: SPR-7672, SPR-8185
GenericWebApplicationContext now implements
ConfigurableWebApplicationContext in order to be compatible with
Framework/DispatcherServlet and ContextLoader/Listener, especially with
regard to changes in SPR-7672 that allow for programmatic use of these
types within Servlet 3.0+ environments. For the first time, it's now
reasonable to imagine injecting a GWAC into DispatcherServlet; the most
robust way to accommodate this possibility is for GWAC to implement
CWAC.
The implementation is in name only, allowing for interchangable use of
GWAC anywhere, for example, an XWAC could otherwise go. Methods such
as setConfigLocation will throw UnsupportedOperationException if the
configLocation value actually contains text. Other methods are
implemented as no-ops or to throw UOE as appropriate.
Issue: SPR-7672
WebApplicationInitializer provides a programmatic alternative to the
traditional WEB-INF/web.xml servlet container deployment descriptor
for Servlet API 3.0+ environments.
This is done by building atop the new ServletContainerInitializer
support in Servlet 3.0. See SpringServletContainerInitializer for
complete details. And see WebApplicationInitializer Javadoc for
typical usage examples.
Issue: SPR-7672
In support of SPR-7672 which will support code-based configuration
alternatives to web.xml using new features in the Servlet 3.0 API.
This upgrade does *not* force Spring users to upgrade to Servlet 3.0
capable containers. Compatibility with and support for
javax.servlet >= 2.4 remains.
Issue: SPR-7672
Calls to AbstractApplicationContext#setParent delegate the parent
context environment to the child.
This ensures that any property sources added to the parent are available
to the child as well as ensuring that any profiles activated are
activated everywhere.
Child contexts may still choose to replace their environment (through an
ApplicationContextInitializer, for example). In any case, however, in
the root/child web application context relationship established by
ContextLoader + DispatcherServlet, the child is guaranteed to have
already been given the parent environment by the time it is delegated
to any ACIs.
See AbstractApplicationContext#setParent for implementation
See FrameworkServlet#createWebApplicationContext for order in which
setParent then initializeWebApplicationContext are called.
Issue: SPR-8185
AnnotationConfigApplicationContext and
AnnotationConfigWebApplicationContext both expose #register and #scan
methods as of the completion of SPR-8320. This change introduces a new
interface that declares each of these methods and refactors ACAC and
ACWAC to implement it.
Beyond information value, this is useful for implementors of the
ApplicationContextInitializer interface, in that users may create an ACI
that works consistently across ACAC and ACWAC for standalone (e.g.
testing, batch) or web (e.g. production) use.
Issue: SPR-8365,SPR-8320
Primarily for use in conjunction with ApplicationContextInitializer,
these new #scan and #register methods mirror those in
AnnotationConfigApplicationContext. #setConfigLocation
and #setConfigLocations methods remain for compatibility with
ContextLoader-style initialization, but have been locally overridden
and documented clearly.
AnnotationConfigWebApplicationContext#loadBeanDefinitions Javadoc has
also been updated to explain the processing logic for each of these
potential inputs.
Issue: SPR-8320
FrameworkServlet now has support equivalent to ContextLoader and its
"contextInitializerClasses" context-param introduced in 3.1 M1.
This allows users to specify ApplicationContextInitializers at the root
(ContextLoader) level and/or at the DispatcherServlet level.
Issue: SPR-8366
The following is now possible:
@Configuration
public class AppConfig {
@Inject DataSource dataSource;
@Bean
public MyBean myBean() {
return new MyBean(dataSource);
}
@Configuration
static class DatabaseConfig {
@Bean
DataSource dataSource() {
return new EmbeddedDatabaseBuilder().build();
}
}
}
public static void main(String... args) {
AnnotationConfigApplicationContext ctx =
new AnnotationConfigApplicationContext(AppConfig.class);
ctx.getBean(MyBean.class); // works
ctx.getBean(DataSource.class); // works
}
Notice that the @Import annotation was not used and that only AppConfig
was registered against the context. By virtue of the fact that
DatabaseConfig is a member class of AppConfig, it is automatically
registered when AppConfig is registered. This avoids an awkward and
redundant @Import annotation when the relationship is already implicitly
clear.
See @Configuration Javadoc for details.
Issue: SPR-8186
ClassMetadata implementations can now introspect their member (nested)
classes. This will allow for automatic detection of nested
@Configuration types in SPR-8186.
Issue: SPR-8358,SPR-8186
This new hook in the AbstractEnvironment lifecycle allows for more
explicit and predictable customization of property sources by
subclasses. See Javadoc and existing implementations for detail.
Issue: SPR-8354
AbstractEnvironment and subclasses now register a reserved default
profile named literally 'default' such that with no action on the part
of the user, beans defined against the 'default' profile will be
registered - if no other profiles are explicitly activated.
For example, given the following three files a.xml, b.xml and c.xml:
a.xml
-----
<beans> <!-- no 'profile' attribute -->
<bean id="a" class="com.acme.A"/>
</beans>
b.xml
-----
<beans profile="default">
<bean id="b" class="com.acme.B"/>
</beans>
c.xml
-----
<beans profile="custom">
<bean id="c" class="com.acme.C"/>
</beans>
bootstrapping all of the files in a Spring ApplicationContext as
follows will result in beans 'a' and 'b', but not 'c' being registered:
ApplicationContext ctx = new GenericXmlApplicationContext();
ctx.load("a.xml");
ctx.load("b.xml");
ctx.load("c.xml");
ctx.refresh();
ctx.containsBean("a"); // true
ctx.containsBean("b"); // true
ctx.containsBean("c"); // false
whereas activating the 'custom' profile will result in beans 'a' and
'c', but not 'b' being registered:
ApplicationContext ctx = new GenericXmlApplicationContext();
ctx.load("a.xml");
ctx.load("b.xml");
ctx.load("c.xml");
ctx.getEnvironment().setActiveProfiles("custom");
ctx.refresh();
ctx.containsBean("a"); // true
ctx.containsBean("b"); // false
ctx.containsBean("c"); // true
that is, once the 'custom' profile is activated, beans defined against
the the reserved default profile are no longer registered. Beans not
defined against any profile ('a') are always registered regardless of
which profiles are active, and of course beans registered
against specific active profiles ('c') are registered.
The reserved default profile is, in practice, just another 'default
profile', as might be added through calling env.setDefaultProfiles() or
via the 'spring.profiles.default' property. The only difference is that
the reserved default is added automatically by AbstractEnvironment
implementations. As such, any call to setDefaultProfiles() or value set
for the 'spring.profiles.default' will override the reserved default
profile. If a user wishes to add their own default profile while
keeping the reserved default profile as well, it will need to be
explicitly redeclared, e.g.:
env.addDefaultProfiles("my-default-profile", "default")
The reserved default profile(s) are determined by the value returned
from AbstractEnvironment#getReservedDefaultProfiles(). This protected
method may be overridden by subclasses in order to customize the
set of reserved default profiles.
Issue: SPR-8203
- removed generics from Cache/CacheManager (they add no value since it's an SPI not API)
+ update docs and tests
+ renamed ConcurrentCacheFactoryBean to ConcurrentMapCacheFactoryBean
Revert signature of
ConfigurationClassPostProcessor#processConfigBeanDefinitions to its form
found in the 3.0.x line. Refactorings made during 3.1 development
caused otherwise package-private types such as
ConfigurationClassBeanDefinitionReader to escape through this public
method, causing issues for STS as well as being a general design issue.
Upon review, the refactorings could easily be backed out in favor of a
simpler approach, and this has been done.
This also means that ConfigurationClassBeanDefinitionReader can return
to package-private visibility, and this change has been made as well.
Issue: SPR-8200
@Autowired, @Value and other annotations cannot be applied within
Spring Bean(Factory)PostProcessor types, because they themselves
are processed using BeanPostProcessors. Javadoc and reference docs
have been updated to reflect.
Issue: SPR-4935, SPR-8213
A subtle issue existed with the way we relied on isCurrentlyInCreation
to determine whether a @Bean method is being called by the container
or by user code. This worked in most cases, but in the particular
scenario laid out by SPR-8080, this approach was no longer sufficient.
This change introduces a ThreadLocal that contains the factory method
currently being invoked by the container, such that enhanced @Bean
methods can check against it to see if they are being called by the
container or not. If so, that is the cue that the user-defined @Bean
method implementation should be invoked in order to actually create
the bean for the first time. If not, then the cached instance of
the already-created bean should be looked up and returned.
See ConfigurationClassPostConstructAndAutowiringTests for
reproduction cases and more detail.
Issue: SPR-8080
If the enclosing environment does not implement ConfigurableEnvironment,
then @PropertySource annotations are ignored because there is no way to
add them to the Environment. Now checking first to see if there are any
@PropertySource annotations present before issuing the warning.
Issue: SPR-8314
Allows a convenient mechanism for contributing a PropertySource to the
enclosing Spring Environment. See @PropertySource Javadoc for
complete details and PropertySourceAnnotationTests for examples.
Issue: SPR-8314
Allows convenient creation of a Properties-based PropertySource from a
Spring Resource object or resource location string such as
"classpath:com/myco/app.properties" or "file:/path/to/file.properties"
Issue: SPR-8328
Users may now call #setRequiredProperties(String...) against the
Environment (via its ConfigurablePropertyResolver interface) in order
to indicate which properties must be present.
Environment#validateRequiredProperties() is invoked by
AbstractApplicationContext during the refresh() lifecycle to perform
the actual check and a MissingRequiredPropertiesException is thrown
if the precondition is not satisfied.
Issue: SPR-8323
Declaring @Bean methods as 'static' is now permitted, whereas previously
it raised an exception at @Configuration class validation time.
A static @Bean method can be called by the container without requiring
the instantiation of its declaring @Configuration class. This is
particularly useful when dealing with BeanFactoryPostProcessor beans,
as they can interfere with the standard post-processing lifecycle
necessary to handle @Autowired, @Inject, @Value, @PostConstruct and
other annotations.
static @Bean methods cannot recieve CGLIB enhancement for scoping and
AOP concerns. This is acceptable in BFPP cases as they rarely if ever
need it, and should not in typical cases ever be called by another
@Bean method. Once invoked by the container, the resulting bean will
be cached as usual, but multiple invocations of the static @Bean method
will result in creation of multiple instances of the bean.
static @Bean methods may not, for obvious reasons, refer to normal
instance @Bean methods, but again this is not likely a concern for BFPP
types. In the rare case that they do need a bean reference, parameter
injection into the static @Bean method is technically an option, but
should be avoided as it will potentially cause premature instantiation
of more beans that the user may have intended.
Note particularly that a WARN-level log message is now issued for any
non-static @Bean method with a return type assignable to BFPP. This
serves as a strong recommendation to users that they always mark BFPP
@Bean methods as static.
See @Bean Javadoc for complete details.
Issue: SPR-8257, SPR-8269
Prior to this change, @ComponentScan annotations were only processed at
the first level of depth. Now, the set of bean definitions resulting
from each declaration of @ComponentScan is checked for configuration
classes that declare @ComponentScan, and recursion is performed as
necessary.
Cycles between @ComponentScan declarations are detected as well. See
CircularComponentScanException.
Issue: SPR-8307
Introduce @EnableAsync#order
AsyncAnnotationBeanPostProcessor's 'order' property is now mutable;
@EnableAsync's 'order()' attribute allows for setting it, but must
have a default value, thus uses the new Ordered#NOT_ORDERED
constant - a reserved negative number very unlikely to be otherwise
used that may be interpreted as 'not ordered', useful in annotation
defaulting scenarios where null is not an option.
Introduce first working cut of AsyncConfiguration
Remove AsyncCapability
This change is in support of certain polymorphism cases in
@Configuration class inheritance hierarchies. Consider the following
scenario:
@Configuration
public abstract class AbstractConfig {
public abstract Object bean();
}
@Configuration
public class ConcreteConfig {
@Override
@Bean
public BeanPostProcessor bean() { ... }
}
ConcreteConfig overrides AbstractConfig's #bean() method with a
covariant return type, in this case returning an object of type
BeanPostProcessor. It is critically important that the container
is able to detect the return type of ConcreteConfig#bean() in order
to instantiate the BPP at the right point in the lifecycle.
Prior to this change, the container could not do this.
AbstractAutowireCapableBeanFactory#getTypeForFactoryMethod called
ReflectionUtils#getAllDeclaredMethods, which returned Method objects
for both the Object and BeanPostProcessor signatures of the #bean()
method. This confused the implementation sufficiently as not to
choose a type for the factory method at all. This means that the
BPP never gets detected as a BPP.
The new method being introduced here, #getUniqueDeclaredMethods, takes
covariant return types into account, and filters out duplicates,
favoring the most specific / narrow return type.
Additionally, it filters out any CGLIB 'rewritten' methods, which
is important in the case of @Configuration classes, which are
enhanced by CGLIB. See the implementation for further details.
Consolidating internal bean name and aspect class name constats within
AnnotationConfigUtils to allow access from both the context.config
and context.annotation packages without creating a relationship between
the two of them (they are unrelated leaf nodes in the packaging
currently).
The .transaction module does not have a similar utils class and already
has a relationship from transaction.config -> transaction.annotation,
so placing the constants in .annotation.TransactionManagementCapability
to be referenced by .config.AnnotationDrivenBeanDefinitionParser
Allows @Enable* a layer of indirection for deciding which @Configuration
class(es) to @Import.
The @Import annotation may now accept @Configuration class literals
and/or ImportSelector class literals.
@Configuration classes may implement ImportAware in order to be injected
with the AnnotationMetadata of their @Import'ing class.
Includes the introduction of a new PriorityOrdered
ImportAwareBeanPostProcessor that handles injection of the
importing class metadata.
Includes the introduction of AnnotationUtils#findAllAnnotationAttributes
to support iterating through all annotations declared on a given type
and interrogating each for the presence of a meta-annotation. See tests
for details.
Feature-related support such as @Feature, @FeatureConfiguration,
and FeatureSpecification types will be replaced by framework-provided
@Configuration classes and convenience annotations such as
@ComponentScan (already exists), @EnableAsync, @EnableScheduling,
@EnableTransactionManagement and others.
Issue: SPR-8012,SPR-8034,SPR-8039,SPR-8188,SPR-8206,SPR-8223,
SPR-8225,SPR-8226,SPR-8227
The overloading necessary to preserve the new signature as well as
the old causes ambiguities leading to deprecation warnings in some
caller scenarios.
- Removed AbstractGenericContextLoader's createGenericApplicationContext() method.
- AnnotationConfigContextLoader now uses an AnnotatedBeanDefinitionReader instead of working with an AnnotationConfigApplicationContext.
- AnnotationConfigContextLoader now uses the supplied GenericApplicationContext to load configuration classes.
SessionFactory objects created by
SessionFactoryBuilderSupport#buildSessionFactory are now DisposableBean
proxies that call SessionFactory#close and release any threadlocal
DataSource object.
This is the same behavior that has always occurred during LSFBean and
ASFBean destruction lifecycles (and still does). This destruction logic
has now been factored out into
SessionFactoryBuilderSupport#closeHibernateSessionFactory such that all
SFB types can reuse it easily.
Note that LSFBean and ASFBean are subclasses, respectively, of SFBuilder
and ASFBuilder and they each must disable the DisposableBean proxying in
order to avoid duplicate attempts at closing the SessionFactory. See
the implementations of wrapSessionFactoryIfNeccesary() for details.
Issue: SPR-8114
Previously, ExtendedBeanInfo would attempt to process methods named
exactly 'set'. JavaBeans properties must have at least one character
following the 'set' prefix in order to qualify, and this is now
respected by EBI.
Thanks to Rob Winch for the patch fixing this problem.
Issue: SPR-8175
Large refactoring of existing *SessionFactoryBean hierarchy designed to
support configuration of Hibernate SessionFactory objects within
@Configuration class @Bean methods without forcing use of a
FactoryBean type, which is generally discouraged due to awkwardness
of programming model and lifecycle issues. Refactored and new types
include:
* Removal of AbstractSessionFactoryBean, replacing it with
SessionFactoryBeanSupport abstract base class
* Introduction of SessionFactoryBuilder and
AnnotationSessionFactoryBuilder types, both direct subclasses of
SessionFactoryBuilderSupport. These types are intended for direct
use within @Bean methods. They expose method-chainable set*
methods allowing for concise and convenient use. See JavaDoc
on both types for usage examples.
* LocalSessionFactoryBean and AnnotationSessionFactoryBean types are
now subclasses, respectively, of the *Builder types above.
LSFB and ASFB backward-compatibility has been maintained almost
entirely. The one exception is that there is no longer a protected
convertHibernateAccessException() method available in the hierarchy.
This method was not likely often used anyway and has been replaced
by the new (and public) setPersistenceExceptionTranslator() which
accepts instances of type HibernateExceptionTranslator as introduced in
SPR-8076.
LSFB and ASFB setter method signatures have changed. They no longer
return void in standard JavaBeans style but rather, and due to extending
the *Builder types above, return the 'this' reference. This posed a
problem because the Spring container has to date been unable to detect
and provide dependency injection against non-void returning setter
methods. This limitation was due to the way that the default JavaBeans
Introspector class and its getBeanInfo() method works, and prompted the
introduction and intergration of ExtendedBeanInfo, already completed in
SPR-8079. So have no concern if you notice this signature change - it
all works.
Certain deprecations have been made:
* All LSFB/ASFB methods related to Hibernate's CacheProvider SPI,
reflecting its deprecation in Hibernate 3.3 in favor of the new
RegionFactory SPI. Note these methods have been preserved only
on the FactoryBean types. The new *SessionFactoryBuilder
supertypes do not expose CacheProvider services at all.
* All protected LSFB/ASFB methods that accept a Hibernate
Configuration parameter, such as newSessionFactory(Configuration),
postProcessMappings(Configuration) and
postProcessConfiguration(Configuation), in favor of no-arg methods
with the same names. Due to the nature of the hierarchy
refactoring mentioned above, the Configuration instance is always
available when these methods are called, thus no need to pass it
in as a parameter.
In the process, our approach to automatic detection of Hibernate dialect
has been improved (it was in fact broken before). Thanks to James
Roper for his suggestion in SPR-7936 as to how to fix this.
See HibernateSessionFactoryConfigurationTests as a starting point for
understanding the new builder-style approach to SessionFactory creation.
Note especially use of the SessionFactoryBuilder#doWithConfiguration
method which allows for direct programmatic configuration of the Native
Hibernate (Annotation)Configuration API.
As a final note, AnnotationConfiguration has been deprecated in
Hibernate 3.6, and great pains have been taken to ensure that users
of any supported Hibernate version (3.2 -> 3.6) will never need to
(a) cast from Configuration to AnnotationConfiguration or (b)
experience deprecation warnings due to being forced to use the
AnnotationConfiguration API. Explore the JavaDoc around the
doWithConfiguration() method and HibernateConfigurationCallback type
for complete details.
Issue: SPR-8066, SPR-7936, SPR-8076, SPR-8098
Designed to allow persistence exception translation of
HibernateException types without being forced to use
LocalSessionFactoryBean types.
Committed now in support of the forthcoming introduction of
*SessionFactoryBuilder types.
Issue: SPR-8076
Decorator for instances returned from
Introspector#getBeanInfo(Class<?>) that supports detection and inclusion
of non-void returning setter methods. Fully supports indexed properties
and otherwise faithfully mimics the default
BeanInfo#getPropertyDescriptors() behavior, e.g., PropertyDescriptor
ordering, etc.
This decorator has been integrated with CachedIntrospectionResults
meaning that, in simple terms, the Spring container now supports
injection of setter methods having any return type.
Issue: SPR-8079
Previously errors were being raised when trying to inject @Value
annotated paramaters such as:
@Feature
public FeatureSpec feature(@Value("#{environment['foo']}") String foo) {
return new FeatureSpec(foo);
}
This is not so much because dependency resolution of @Value-annotated
types was failing, but rather because the 'early bean reference'
proxying mechanism was throwing an exception if any final type was
detected as a parameter. This is of course because final types are
non-subclassable by CGLIB. On review, however, it's obvious that
certain final types must be allowed for injection. @Value injection
is an obvious one, but the rarer case of a Spring bean of type String
or int is another.
The explicit guard against final types as parameters to @Feature methods
has been removed. Final types are still checked for, however, and if
found, no proxing is attempted. The dependency is immediately resolved
against the current BeanFactory and injected into the @Feature method.
This means that @Value injection, @Qualifier injection, etc all work
as expected, but does mean that premature bean instantiation may occur
if a user unwittingly injects non-String, non-primitive final bean types
as @Feature method parameters.
Issue: SPR-7974
CGLIB-enhanced @Configuration subclasses now implement DisposableBean
such that Enhancer.registerStaticCallbacks(subclass, null) is invoked
on container shutdown. This ensures that garbage collection can work
properly and avoids memory consumption issues for applications that
create and destroy many application contexts within the same JVM.
Issue: SPR-7901
context:property-placeholder extends 'propertyPlaceholder' type
defintion once again. This relationship was inadvertently removed in
3.1 M1, and the effect was that XML tooling would raise errors on
use of attributes like 'location'.
The updated schema has also been published to
http://www.springframework.org/schema/context/spring-context-3.1.xsd
Issue: SPR-8037
Prove that injection of special container types such as ResourceLoader,
BeanFactory, etc already works with the current implementation of
@Feature methods.
Issue: SPR-7975
Previously, only commas could delimit <beans profile="p1,p2"/>. Now, as
with <bean alias="..."/>, the profile attribute allows for delimiting
by comma, space and/or semicolon.
BeanDefinitionParserDelegate.MULTI_VALUE_ATTRIBUTE_DELIMITERS has been
added as a constant to reflect the fact this set of delimiters is used
in multiple locations throughout the framework.
BDPD.BEAN_NAME_DELIMITERS now refers to the above and has been has been
preserved but deprecated for backward compat (though use outside the
framework is unlikely).
Changes originally based on user comment at
http://blog.springsource.com/2011/02/11/spring-framework-3-1-m1-released/comment-page-1/#comment-184455
Issue: SPR-8033
Current STS version of Spring (3.0.5) does not contain
the BeanUtils.instantiateClass(Class<?>, Class<T>) signature
that was added in 3.1.0, therefore NoSuchMethodErrors are
being thrown when STS classloads and delegates to
3.1.0 NamespaceHandler and BeanDefinitionParser implementations
on the user project classpath.
In this case, it's AbstractSpecificationBeanDefinitionParser
doing the calling to the unknown new method. In this specific
example, reverting back to the old single-arg signature is actually
not a problem, because it does accept Class<T> and returns an
instance of type T, which was the desired behavior in the first
place.
The newer signature remains in order to accommodate callers
who do not know the generic type of the Class to be instantiated
(i.e. Class<?>), but do know the type that it should be assignable
to -- this becomes the second argument Class<T>, and an instance
of type T is returned (if indeed it is assignable to the specified
type; otherwise IllegalArgumentException.
Defensively catch NoSuchMethodError when calling BDPD.getEnvironment()
and supply a DefaultEnvironment if not available.
Replace the single-arg constructor for BDPD and deprecate, preserving
binary compat particularly for Spring Integration who instantiates
this class directly, which is unusual.
Revert changes to ParserContext, ReaderContext, and XmlReaderContext
These changes cause cross-version incompatibilities at tooling time
-- for instance, an STS version that ships with Spring 3.0.5
classloads the ParserContext defined in that version, whereas it
classloads NamespaceHandlers and BeanDefinitionParsers (by default)
from the user application classpath, which may be building against
3.1.0. If so, the changes introduced to these types in 3.1.0 are
incompatible with expectations in the 3.0.5 world and cause all
manner of problems. In this case, it was NoSuchMethodError due to
the newly-added XmlReaderContext.getProblemReporter() method; also
IncompatibleClassChangeError due to the introduction of the
ComponentRegistrar interface on ParserContext.
Each of these problems have been mitigated, though the solutions
are not ideal. The method mentioned has been removed, and instead
the problemReporter field is now accessed reflectively.
ParserContext now no longer implements ComponentRegistrar, and
rather a ComponentRegistrarAdapter class has been introduced that
passes method calls through to a ParserContext delegate.
Introduce AbstractSpecificationBeanDefinitionParser
AbstractSpecificationBeanDefinitionParser has been introduced in
order to improve the programming model for BeanDefinitionParsers
that have been refactored to the new FeatureSpecification model.
This new base class and it's template method implementation of
parse/doParse ensure that common concerns like (1) adapting a
ParserContext into a SpecificationContext, (2) setting source and
source name on the specification, and (3) actually executing the
specification are all managed by the base class. The subclass
implementation of doParse need only actually parse XML, populate
and return the FeatureSpecification object. This change removed
the many duplicate 'createSpecificationContext' methods that had
been lingering.
Minor improvement to BeanDefinitionReaderUtils API
Introduced new BeanDefinitionReaderUtils#registerWithGeneratedName
variant that accepts BeanDefinition as opposed to
AbstractBeanDefinition, as BeanDefinition is all that is actually
necessary to satisfy the needs of the method implementation. The
latter variant accepting AbstractBeanDefinition has been deprecated
but remains intact and delegates to the new variant in order to
maintain binary compatibility.
This change broke binary compatibility as evidenced by running
the greenhouse test suite and finding that Spring Integration's
AbstractConsumerEndpointParser.parseInternal fails with
NoSuchMethodError when trying to invoke.
Introduce FeatureSpecification interface and implementations
FeatureSpecification objects decouple the configuration of
spring container features from the concern of parsing XML
namespaces, allowing for reuse in code-based configuration
(see @Feature* annotations below).
* ComponentScanSpec
* TxAnnotationDriven
* MvcAnnotationDriven
* MvcDefaultServletHandler
* MvcResources
* MvcViewControllers
Refactor associated BeanDefinitionParsers to delegate to new impls above
The following BeanDefinitionParser implementations now deal only
with the concern of XML parsing. Validation is handled by their
corresponding FeatureSpecification object. Bean definition creation
and registration is handled by their corresponding
FeatureSpecificationExecutor type.
* ComponentScanBeanDefinitionParser
* AnnotationDrivenBeanDefinitionParser (tx)
* AnnotationDrivenBeanDefinitionParser (mvc)
* DefaultServletHandlerBeanDefinitionParser
* ResourcesBeanDefinitionParser
* ViewControllerBeanDefinitionParser
Update AopNamespaceUtils to decouple from XML (DOM API)
Methods necessary for executing TxAnnotationDriven specification
(and eventually, the AspectJAutoProxy specification) have been
added that accept boolean arguments for whether to proxy
target classes and whether to expose the proxy via threadlocal.
Methods that accepted and introspected DOM Element objects still
exist but have been deprecated.
Introduce @FeatureConfiguration classes and @Feature methods
Allow for creation and configuration of FeatureSpecification objects
at the user level. A companion for @Configuration classes allowing
for completely code-driven configuration of the Spring container.
See changes in ConfigurationClassPostProcessor for implementation
details.
See Feature*Tests for usage examples.
FeatureTestSuite in .integration-tests is a JUnit test suite designed
to aggregate all BDP and Feature* related tests for a convenient way
to confirm that Feature-related changes don't break anything.
Uncomment this test and execute from Eclipse / IDEA. Due to classpath
issues, this cannot be compiled by Ant/Ivy at the command line.
Introduce @FeatureAnnotation meta-annotation and @ComponentScan impl
@FeatureAnnotation provides an alternate mechanism for creating
and executing FeatureSpecification objects. See @ComponentScan
and its corresponding ComponentScanAnnotationParser implementation
for details. See ComponentScanAnnotationIntegrationTests for usage
examples
Introduce Default[Formatting]ConversionService implementations
Allows for convenient instantiation of ConversionService objects
containing defaults appropriate for most environments. Replaces
similar support originally in ConversionServiceFactory (which is now
deprecated). This change was justified by the need to avoid use
of FactoryBeans in @Configuration classes (such as
FormattingConversionServiceFactoryBean). It is strongly preferred
that users simply instantiate and configure the objects that underlie
our FactoryBeans. In the case of the ConversionService types, the
easiest way to do this is to create Default* subtypes. This also
follows convention with the rest of the framework.
Minor updates to util classes
All in service of changes above. See diffs for self-explanatory
details.
* BeanUtils
* ObjectUtils
* ReflectionUtils
Designed primarily for use in conjunction with web applications
to provide a convenient mechanism for configuring the container
programmatically.
ApplicationContextInitializer implementations are specified through the
new "contextInitializerClasses" servlet context parameter, then detected
and invoked by ContextLoader in its customizeContext() method.
In any case, the semantics of ApplicationContextInitializer's
initialize(ConfigurableApplicationContext) method require that
invocation occur *prior* to refreshing the application context.
ACI implementations may also implement Ordered/PriorityOrdered and
ContextLoader will sort instances appropriately prior to invocation.
Specifically, this new support provides a straightforward way to
programmatically access the container's Environment for the purpose
of adding, removing or otherwise manipulating PropertySource objects.
See Javadoc for further details.
Also note that ApplicationContextInitializer semantics overlap to
some degree with Servlet 3.0's notion of ServletContainerInitializer
classes. As Spring 3.1 development progresses, we'll likely see
these two come together and further influence one another.
DefaultWebEnvironment automatically adds a JndiPropertySource if
a "jndiPropertySourceEnabled" property is detected in any of the
other other default property sources.
* PropertySources is now an Iterable<PropertySource> in favor of
exposing an asList() method
* Otherwise reduced the set of methods exposed by PropertySources to the
absolute minimum
* Added Javadoc for both types and all methods
PropertySourcesPlaceholderConfigurer accommodates recent changes in
Environment and PropertySource APIs, e.g. no longer assuming enumerability
of property names.
PSPC reuses as much functionality as possible from
AbstractPropertyPlaceholderConfigurer, but overrides
postProcessBeanFactory() and defines its own variation on
processProperties() in order to accept a PropertyResolver rather than
a PropertySource.
AbstractPropertyPlaceholderConfigurer introduces doProcessProperties()
method to encapsulate that which is actually common, such as the
visiting of each bean definition once a StringValueResolver has been
created in the subclass.
* Environment now extends PropertyResolver
* Environment no longer exposes resolver and sources
* PropertySource is String,Object instead of String,String
* PropertySource no longer assumes enumerability of property names
* Introduced EnumerablePropertySource for those that do have enumerable property names
All existing *Aware interfaces have been refactored to extend this
new marker interface, serving two purposes:
* Easy access to a type hierarchy that can answer the question
"What *Aware interfaces are available?", without requiring
text-based searches. Also clearly excludes false positives like
TargetClassAware and ParamAware, which while similarly named,
are not semantically similar to traditional *Aware interfaces
in Spring.
* Minor potential performance improvements in
AbstractAutowireCapableBeanFactory and
ApplicationContextAwareProcessor. Both have blocks of sequential
instanceof checks in order to invoke any *Aware interface callback
methods. For a bean that implements none of these interfaces,
the whole sequence can be avoided by guarding first with
if (bean instanceof Aware) {
...
}
Implementors of custom *Aware-style interfaces (and presumably
the BeanPostProcessors that handle them), are encouraged to refactor to
extending this interface for consistency with the framework as well as
the points above.
Decomposed Environment interface into PropertySources, PropertyResolver
objects
Environment interface and implementations are still present, but
simpler.
PropertySources container aggregates PropertySource objects;
PropertyResolver provides search, conversion, placeholder
replacement. Single implementation for now is
PropertySourcesPlaceholderResolver
Renamed EnvironmentAwarePropertyPlaceholderConfigurer to
PropertySourcesPlaceholderConfigurer
<context:property-placeholder/> now registers PSPC by default, else
PPC if systemPropertiesMode* settings are involved
Refined configuration and behavior of default profiles
See Environment interface Javadoc for details
Added Portlet implementations of relevant interfaces:
* DefaultPortletEnvironment
* PortletConfigPropertySource, PortletContextPropertySource
* Integrated each appropriately throughout Portlet app contexts
Added protected 'createEnvironment()' method to AbstractApplicationContext
Subclasses can override at will to supply a custom Environment
implementation. In practice throughout the framework, this is how
Web- and Portlet-related ApplicationContexts override use of the
DefaultEnvironment and swap in DefaultWebEnvironment or
DefaultPortletEnvironment as appropriate.
Introduced "stub-and-replace" behavior for Servlet- and Portlet-based
PropertySource implementations
Allows for early registration and ordering of the stub, then
replacement with actual backing object at refresh() time.
Added AbstractApplicationContext.initPropertySources() method to
support stub-and-replace behavior. Called from within existing
prepareRefresh() method so as to avoid impact with
ApplicationContext implementations that copy and modify AAC's
refresh() method (e.g.: Spring DM).
Added methods to WebApplicationContextUtils and
PortletApplicationContextUtils to support stub-and-replace behavior
Added comprehensive Javadoc for all new or modified types and members
Added XSD documentation for all new or modified elements and attributes
Including nested <beans>, <beans profile="..."/>, and changes for
certain attributes type from xsd:IDREF to xsd:string
Improved fix for detecting non-file based Resources in
PropertiesLoaderSupport (SPR-7547, SPR-7552)
Technically unrelated to environment work, but grouped in with
this changeset for convenience.
Deprecated (removed) context:property-placeholder
'system-properties-mode' attribute from spring-context-3.1.xsd
Functionality is preserved for those using schemas up to and including
spring-context-3.0. For 3.1, system-properties-mode is no longer
supported as it conflicts with the idea of managing a set of property
sources within the context's Environment object. See Javadoc in
PropertyPlaceholderConfigurer, AbstractPropertyPlaceholderConfigurer
and PropertySourcesPlaceholderConfigurer for details.
Introduced CollectionUtils.toArray(Enumeration<E>, A[])
Work items remaining for 3.1 M2:
Consider repackaging PropertySource* types; eliminate internal use
of SystemPropertyUtils and deprecate
Further work on composition of Environment interface; consider
repurposing existing PlaceholderResolver interface to obviate need
for resolve[Required]Placeholder() methods currently in Environment.
Ensure configurability of placeholder prefix, suffix, and value
separator when working against an AbstractPropertyResolver
Add JNDI-based Environment / PropertySource implementatinos
Consider support for @Profile at the @Bean level
Provide consistent logging for the entire property resolution
lifecycle; consider issuing all such messages against a dedicated
logger with a single category.
Add reference documentation to cover the featureset.
Changed the documentation to correctly state that B(F)PP are instantiated eagerly no matter if they are explicitly marked as to be lazy initialized or the default-lazy-init attribute is used at a <beans /> element.
+ add support for multiple cache names
+ require each annotation to specify a cache name
+ add method support in Key generator interface
+ add bug fix for embedded JDK concurrent declaration
AbstractEnvironment delegates to an underlying ConfigurationService when
processing methods such as getProperty(String name, Class<?> targetType)
Accessor methods have been added to the ConfigurableEnvironment
interface that allow this service to be updated or replaced.
There is no longer a reserved default profile named 'default'. Rather,
users must explicitly specify a default profile or profiles via
ConfigurableEnvironment.setDefaultProfiles(String...)
- or -
spring.profile.default="pD1,pD2"
Per above, the setDefaultProfile(String) method now accepts a variable
number of profile names (one or more). This is symmetrical with the
existing setActiveProfiles(String...) method.
A typical scenario might involve setting both a default profile as a
servlet context property in web.xml and then setting an active profile
when deploying to production.
Before this change, the following properties could be used to manipulate
Spring profile behavior:
-DspringProfiles=p1,p2
-DdefaultSpringProfile=pD
These properties have been renamed to follow usual Java conventions for
property naming:
-Dspring.profile.active=p1,p2
-Dspring.profile.default=pD
'default' is now a reserved profile name, indicating
that any beans defined within that profile will be registered
unless another profile or profiles have been activated.
Examples below are expressed in XML, but apply equally when
using the @Profile annotation.
EXAMPLE 1:
<beans>
<beans profile="default">
<bean id="foo" class="com.acme.EmbeddedFooImpl"/>
</beans>
<beans profile="production">
<bean id="foo" class="com.acme.ProdFooImpl"/>
</beans>
</beans>
In the case above, the EmbeddedFooImpl 'foo' bean will be
registered if:
a) no profile is active
b) the 'default' profile has explicitly been made active
The ProdFooImpl 'foo' bean will be registered if the 'production'
profile is active.
EXAMPLE 2:
<beans profile="default,xyz">
<bean id="foo" class="java.lang.String"/>
</beans>
Bean 'foo' will be registered if any of the following are true:
a) no profile is active
b) 'xyz' profile is active
c) 'default' profile has explicitly been made active
d) both (b) and (c) are true
Note that the default profile is not to be confused with specifying no
profile at all. When the default profile is specified, beans are
registered only if no other profiles are active; whereas when no profile
is specified, bean definitions are always registered regardless of which
profiles are active.
The default profile may be configured programmatically:
environmnent.setDefaultProfile("embedded");
or declaratively through any registered PropertySource, e.g. system properties:
-DdefaultSpringProfile=embedded
Assuming either of the above, example 1 could be rewritten as follows:
<beans>
<beans profile="embedded">
<bean id="foo" class="com.acme.EmbeddedFooImpl"/>
</beans>
<beans profile="production">
<bean id="foo" class="com.acme.ProdFooImpl"/>
</beans>
</beans>
It is unlikely that use of the default profile will make sense in
conjunction with a statically specified 'springProfiles' property.
For example, if 'springProfiles' is specified as a web.xml context
param, that profile will always be active for that application,
negating the possibility of default profile bean definitions ever
being registered.
The default profile is most useful for ensuring that a valid set of
bean definitions will always be registered without forcing users
to explictly specify active profiles. In the embedded vs. production
examples above, it is assumed that the application JVM will be started
with -DspringProfiles=production when the application is in fact in
a production environment. Otherwise, the embedded/default profile bean
definitions will always be registered.
Earlier naming reflected initial conception of 'environment-specific
bean definitions'. This notion has evolved into bean definitions
specific to particular profiles, and the new naming more clearly
expresses it.
Branch in question is 'env' branch from git://git.springsource.org/sandbox/cbeams.git; merged into
git-svn repository with:
git merge -s recursive -Xtheirs --no-commit env
No merge conflicts, but did need to
git rm spring-build
prior to committing.
With this change, Spring 3.1.0 development is now happening on SVN
trunk. Further commits to the 3.0.x line will happen in an as-yet
uncreated SVN branch. 3.1.0 snapshots will be available
per the usual nightly CI build from trunk.
This is where the master build that creates releases of Spring Framework resides. The build system is based on spring-build, which is linked in using an SVN external to https://src.springframework.org/svn/spring-build.
This is where the master build that creates releases of Spring Framework resides.
The build system is based on spring-build, which is linked in using an SVN
external to https://src.springframework.org/svn/spring-build.
Build Pre-requisites:
- javac 1.6 or > must be in your system path
- ant 1.7 or > must be in your system path
- set ANT_OPTS as follows (to avoid out of memory errors):
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Chris Beams