Update the ReflectiveMethodResolver and ReflectivePropertyAccessor
to allow methods and properties of java.lang.Class to be resolved
when the target object is a class.
Issue: SPR-9017
Attempting to register a custom MethodFilter with a
StandardEvaluationContext after invoking setMethodResolvers() with a
custom list of MethodResolver instances results in a
NullPointerException. Based on the current documentation in
StandardEvaluationContext it is unclear what the expected behavior
should be, but either the implementation is broken, or the use case is
unsupported. In either case, allowing a NullPointerException to be
thrown is inappropriate.
This commit documents the fact that the SpEL MethodFilter is intended to
be used with the ReflectiveMethodResolver. Furthermore,
StandardEvaluationContext.registerMethodFilter() now throws an
IllegalStateException if the user attempts to set a filter after having
registered a custom set of resolvers.
Issue: SPR-9621
The Spring Expression Language currently supports nested single quotes
within expressions but not nested double quotes.
The SpEL tokenizer has been modified to support nested double quotes in
the same way it supports single quotes. A sequence of two double quotes
will now be replaced by one when evaluated.
Extra error handling has also been added to report when invalid escaping
is encountered, since SpEL does not support escaping with backslash.
Issue: SPR-9620
SpEL typically supports logical operators for boolean expressions
consistent with standard Java language syntax. However, the operators
for logical AND and logical OR are currently only supported as textual
operators. In other words, SpEL does not support the use of && and || as
logical operators.
The SpEL tokenizer has now been modified to recognize && and || as
symbolic boolean operators. The parser has been modified to allow the
use of either the textual or symbolic operators.
Issue: SPR-9614
Prior to this commit null literals in SpEL expressions had to be
specified as "null" (i.e., all lowercase).
With this commit null literals in SpEL expressions are interpreted in a
case-insensitive manner, analogous to the current support for boolean
literals.
Issue: SPR-9613
When attempting to parse an Integer literal expression such as
42.toString(), SpEL currently throws a SpelParseException with a message
similar to: "EL1041E:(pos 3): After parsing a valid expression, there is
still more data in the expression: 'toString'". The problem here is that
'3.' is currently considered a valid number (including the dot).
However, SpEL succeeds at parsing an equivalent expression for a Double
literal such as 3.14.isInfinite().
To address this issue, the SpEL Tokenizer no longer consumes the
trailing '.' on an integer as part of the integer. So '3.foo()' will now
be parsed as '3' '.' 'foo()' and not '3.' 'foo()' -- which was what
prevented parsing of method invocations on integers. To keep the change
simple, the parser will no longer handle real numbers of the form
'3.e4'. From now on they must include the extra 0 (i.e., '3.0e4').
Issue: SPR-9612
For legacy reasons, a MockEnvironment implementation already exists in multiple places within Spring's test suite; however, it is not available to the general public.
This commit promotes MockEnvironment to a first-class citizen in the spring-test module, alongside the existing MockPropertySource.
In addition, the following house cleaning has been performed.
- deleted MockPropertySource from the spring-expression module
- deleted MockEnvironment from the "spring" integration testing module
- updated test copies of MockPropertySource and MockEnvironment
- documented MockEnvironment and MockPropertySource in the testing
chapter of the reference manual
Issue: SPR-9492
Prior to this change, SpEL would not allow the use of '[]' in
expressions like the following:
T(foo.Bar[])
This commit updates TypeReference and InternalSpelExpressionParser to
support this syntax, avoiding the need for workarounds like:
new foo.bar[0].class
Issue: SPR-9203
Before this fix ReflectivePropertyAccessor was not able to find write
method for valid property name that has first character in lower case
and second character in upper case. Write method lookup would always
convert first character of property name to upper case which is not
compliant with JavaBean specification. As consequence this caused an
unwanted behavior in SpEL when obtaining values of expressions that
reference such JavaBean properties.
As of this change, write method lookup skips conversion of property
name first character to upper case when property name is longer than
one character and second character is in upper case. This also fixes
mentioned bug in SpEL value resolution.
Issue: SPR-9123
The JavaDoc in OpMultiply contained special characters that caused
problems when building with Java 7 on Mac OS X. The section symbol has
been replaced with the word "Section". Also improved class-level and
method-level JavaDoc in general.
Prior to this commit, SpEL's OpPlus ('+' operator) would convert its
left and right operands to String directly via #toString calls.
This change ensures that operand values are delegated to any registered
converters, allowing for customization of the stringified output.
Note that the OpPlus constructor now throws IllegalArgumentException if
zero operands are supplied.
Issue: SPR-8308
Before this change there were numerous javadoc warnings being reported
while building Spring framework API.
This commit resolves most of the javadoc warnings, reducing the total
number from 265 to 103.
Issue: SPR-9113
Before this change javadoc in two classes had non-UTF-8 encoded
characters. This caused building Spring API to fail in Java 1.7.
Commit fixes this by replacing wrongly encoded characters with their
UTF-8 equivalents.
Issue: SPR-9097
* 3.1.x: (61 commits)
Compensate for changes in JDK 7 Introspector
Avoid 'type mismatch' errors in ExtendedBeanInfo
Polish ExtendedBeanInfo and tests
Infer AnnotationAttributes method return types
Minor fix in MVC reference doc chapter
Hibernate 4.1 etc
TypeDescriptor equals implementation accepts annotations in any order
"setBasenames" uses varargs now (for programmatic setup; SPR-9106)
@ActiveProfiles mechanism works with @ImportResource as well (SPR-8992
polishing
clarified Resource's "getFilename" method to consistently return null
substituteNamedParameters detects and unwraps SqlParameterValue object
Replace spaces with tabs
Consider security in ClassUtils#getMostSpecificMethod
Adding null check for username being null.
Improvements for registering custom SQL exception translators in app c
SPR-7680 Adding QueryTimeoutException to the DataAccessException hiera
Minor polish in WebMvcConfigurationSupport
Detect overridden boolean getters in ExtendedBeanInfo
Polish ExtendedBeanInfoTests
...
This renaming more intuitively expresses the relationship between
subprojects and the JAR artifacts they produce.
Tracking history across these renames is possible, but it requires
use of the --follow flag to `git log`, for example
$ git log spring-aop/src/main/java/org/springframework/aop/Advisor.java
will show history up until the renaming event, where
$ git log --follow spring-aop/src/main/java/org/springframework/aop/Advisor.java
will show history for all changes to the file, before and after the
renaming.
See http://chrisbeams.com/git-diff-across-renamed-directories
Phillip Webb
Andy Clement
Andy Clement
Sam Brannen
Chris Beams
Stevo Slavic
Rossen Stoyanchev
Ivo Smid