The Spring codebase sometimes ignores exceptions in catch blocks on
purpose. This is often called out by an inline comment.
We should make this more obvious by renaming the exception argument in
the catch block to declare whether the exception is "ignored" or
"expected".
See gh-35047
Signed-off-by: Vincent Potucek <vpotucek@me.com>
[brian.clozel@broadcom.com: rework commit message]
Signed-off-by: Brian Clozel <brian.clozel@broadcom.com>
Use HexFormat to perform conversion for unicode-prefixed Strings in CharacterEditor.
Closes gh-34798
Signed-off-by: Patrick Strawderman <pstrawderman@netflix.com>
Prior to this commit, argument index handling in
AutowiredArgumentsCodeGenerator suffered from an off-by-one error when
generating code for an autowired inner class constructor.
Since the startIndex is already properly calculated for an inner class in
InstanceSupplierCodeGenerator.buildGetInstanceMethodForConstructor(...),
there is no need to adjust the argument indexes within
AutowiredArgumentsCodeGenerator.generateCode(...).
Closes gh-34974
Signed-off-by: Dmytro Nosan <dimanosan@gmail.com>
The KotlinDelegate#isNullable invocation is unnecessary since this check
is already done by the Nullness#forField one introduced by
b5d153febf.
See gh-34952
See gh-34261
BeanDefinitionDsl is allowing to create a bean from a callable
reference with its parameters autowired by type,
BeanRegistrarDsl should allow that too. For example:
class SampleBeanRegistrar : BeanRegistrarDsl({
registerBean<MyRepository>()
registerBean(::myRouter)
})
fun myRouter(myRepository: MyRepository) = router {
...
}
Closes gh-34922
After the bootstrap phase (and with spring.locking.strict=true during the bootstrap phase), getSingletonFactoryBeanForTypeCheck always locks. In a background bootstrap thread, it never locks. Otherwise, it tries locking and explicitly resolves the bean class for subsequent type-based resolution (even for a component-scanned class) when it fails to acquire the lock. Furthermore, getObjectFromFactoryBean follows the same locking algorithm for post-processing.
Closes gh-34902
Spring Framework 6.2 introduced support for an escape character for
property placeholders (by default '\'). However, as of Spring Framework
6.2.6, there was no way to either escape the escape character or disable
escape character support.
For example, given a `username` property configured with the value of
`Jane.Smith` and a `DOMAIN\${username}` configuration string, property
placeholder replacement used to result in `DOMAIN\Jane.Smith` prior to
6.2 but now results in `DOMAIN${username}`. Similarly, an attempt to
escape the escape character via `DOMAIN\\${username}` results in
`DOMAIN\${username}`.
In theory, one should be able to disable use of an escape character
altogether, and that is currently possible by invoking
setEscapeCharacter(null) on AbstractPropertyResolver and
PlaceholderConfigurerSupport (the superclass of
PropertySourcesPlaceholderConfigurer).
However, in reality, there are two hurdles.
- As of 6.2.6, an invocation of setEscapeCharacter(null) on a
PropertySourcesPlaceholderConfigurer applied to its internal
top-level PropertySourcesPropertyResolver but not to any nested
PropertySourcesPropertyResolver, which means that the `null` escape
character could not be effectively applied.
- Users may not have an easy way to explicitly set the escape character
to `null` for a PropertyResolver or
PropertySourcesPlaceholderConfigurer. For example, Spring Boot
auto-configures a PropertySourcesPlaceholderConfigurer with the
default escape character enabled.
This first issue above has recently been addressed by gh-34861.
This commit therefore addresses the second issue as follows.
- To allow developers to easily revert to the pre-6.2 behavior without
changes to code or configuration strings, this commit introduces a
`spring.placeholder.escapeCharacter.default` property for use with
SpringProperties which globally sets the default escape character that
is automatically configured in AbstractPropertyResolver and
PlaceholderConfigurerSupport.
- Setting the property to an empty string sets the default escape
character to `null`, effectively disabling the default support for
escape characters.
spring.placeholder.escapeCharacter.default =
- Setting the property to any other character sets the default escape
character to that specific character.
spring.placeholder.escapeCharacter.default = ~
- Setting the property to a string containing more than one character
results in an exception.
- Developers are still able to configure an explicit escape character
in AbstractPropertyResolver and PlaceholderConfigurerSupport if they
choose to do so.
- Third-party components that wish to rely on the same feature can
invoke AbstractPropertyResolver.getDefaultEscapeCharacter() to obtain
the globally configured default escape character.
See gh-9628
See gh-34315
See gh-34861
Closes gh-34865
PropertyPlaceholderConfigurer and PreferencesPlaceholderConfigurer have
been officially deprecated since Spring Framework 5.2.
Since we no longer expect applications to depend on these outdated
mechanisms, this commit deprecates these classes "for removal" in
Spring Framework 8.0.
Closes gh-34880
This commit makes BeanDefinitionPropertyValueCodeGeneratorDelegates
public and offer a convenience method to create a ValueCodeGenerator
that works will all core delegates.
Closes gh-34761
Specifically, the documentation update reflects that:
- Initially, it was mentioned that only the `BeanFactoryAware`
interface is ignored by default.
- The updated documentation now correctly states that `BeanNameAware`,
`BeanFactoryAware`, and `BeanClassLoaderAware` interfaces are all
ignored by default.
This change ensures a more accurate representation of the default
behavior regarding which dependency interfaces are automatically
ignored during autowiring in the context of Spring's bean factory
mechanism.
Closes gh-34747
Signed-off-by: lituizi <2811328244@qq.com>
