Prior to this commit, if AOP proxy generation was configured with
proxyTargetClass=true (which is the default behavior in recent versions
of Spring Boot), beans implemented as lambda expressions or method
references could not be proxied with CGLIB on Java 16 or higher without
specifying `--add-opens java.base/java.lang=ALL-UNNAMED`.
This commit addresses this shortcoming by ensuring that beans
implemented as lambda expressions or method references are always
proxied using a JDK dynamic proxy even if proxyTargetClass=true.
Closes gh-27971
Prior to this commit, the QuartzCronField::weekdayNearestTo would elapse
until the next month before checking if the current day matched.
After this commit, the current day is checked before we elapse until
the next month.
Closes gh-27966
In a small minority of cases, the multipart boundary can spread across
three incoming buffers.
Prior to this commit, MultipartParser.BodyState only supported two
buffers. If the boundary is spread across three buffers, the first
buffer of the three is sent as a whole, even though it contains the
first bytes of the boundary.
This commit fixes this bug, by enqueuing all prior buffers in a queue,
and emitting the ones that cannot contain boundary bytes.
Closes gh-27939
Prior to this commit, the USER_DECLARED_METHODS MethodFilter in
ReflectionUtils did not actually filter methods declared in
java.lang.Object as stated in its Javadoc.
Consequently, if ReflectionUtils.doWithMethods was invoked with
USER_DECLARED_METHODS and Object.class as the class to introspect, all
non-bridge non-synthetic methods declared in java.lang.Object were
passed to the supplied MethodCallback, which breaks the contract of
USER_DECLARED_METHODS.
In addition, if USER_DECLARED_METHODS was composed with a custom
MethodFilter using `USER_DECLARED_METHODS.and(<custom MethodFilter>)`,
that composed method filter allowed all non-bridge non-synthetic
methods declared in java.lang.Object to be passed to the supplied
MethodCallback, which also breaks the contract of
USER_DECLARED_METHODS. This behavior resulted in regressions in code
that had previously used USER_DECLARED_METHODS by itself and then began
using USER_DECLARED_METHODS in a composed filter. For example, since
commit c419ea7ba7 ReflectiveAspectJAdvisorFactory has incorrectly
processed methods in java.lang.Object as candidates for advice methods.
This commit fixes this bug and associated regressions by ensuring that
USER_DECLARED_METHODS actually filters methods declared in
java.lang.Object. In addition, ReflectionUtils.doWithMethods now aborts
its search algorithm early if invoked with the USER_DECLARED_METHODS
filter and Object.class as the class to introspect.
Closes gh-27970
Prior to this commit, we only (indirectly) configured external Javadoc
links for types in the javax.annotation package for JSR 250, since
those types are part of Java 8 SE. However, an external Javadoc link
for types from JSR 305 was not configured.
To address this issue, this commit now configures an external Javadoc
link for JSR 305 types. However, the external Javadoc link for JSR 305
must be configured last to ensure that types from JSR 250 (such as
@PostConstruct) are still supported. This is due to the fact that JSR
250 and JSR 305 both define types in javax.annotation, which results in
a split package, and the javadoc tool does not support split packages
across multiple external Javadoc sites. Instead, the Javadoc tool
iterates over all external links, and the first external site that
claims to support a given package (via the package-list file) wins.
This means:
- Javadoc for JSR 250 annotations is fully supported.
- Javadoc for JSR 305 annotations in the javax.annotation package will
continue to result in a 404 (page not found) error.
- Javadoc for JSR 305 annotations in the javax.annotation.meta package
is fully supported.
For Spring Framework 6.0, the Javadoc for JSR 250 types in
jakarta.annotation package is served from the JBoss Application Server
Javadoc site instead of from Oracle's Java SE documentation site, since
JSR 250 annotations are no longer included in Java SE.
Closes gh-27904
Prior to this commit, if a PropertySourcesPlaceholderConfigurer bean
was configured with its ignoreUnresolvablePlaceholders flag set to
true, unresolvable placeholders in an @Value annotation were not
ignored, resulting in a BeanCreationException for the bean using @Value.
For example, given a property declared as `my.app.var = ${var}` without
a corresponding `var` property declared, an attempt to resolve
`@Value("${my.app.var}")` resulted in the following exception.
java.lang.IllegalArgumentException: Could not resolve placeholder 'var' in value "${var}"
This commit fixes this by modifying
PropertySourcesPlaceholderConfigurer's postProcessBeanFactory(...)
method so that a local PropertyResolver is created if the
ignoreUnresolvablePlaceholders flag is set to true. The local
PropertyResolver then enforces that flag, since the Environment in the
ApplicationContext is most likely not configured with
ignoreUnresolvablePlaceholders set to true.
Closes gh-27947
Juergen Hoeller
Sam Brannen
Stephane Nicoll
Pavel Anisimov
rstoyanchev
Arjen Poutsma
wkwkhautbois
Adam Ostrožlík
Antoine Rey
shirohoo
Jerome Prinet