Spring/spring-framework
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

SpEL documentation refinements (backported from 5.1.x)

Browse Source
This commit is contained in:
Juergen Hoeller
2019-05-13 19:20:58 +02:00
parent 6eeb065036
commit 1345ec902e
1 changed files with 27 additions and 27 deletions
Download Patch File Download Diff File Expand all files Collapse all files

54
src/asciidoc/core-expressions.adoc
View File

@@ -119,11 +119,12 @@ as shown below.
byte[] bytes = (byte[]) exp.getValue();
----
SpEL also supports nested properties using the standard _dot_ notation, i.e.
`prop1.prop2.prop3` and also the corresponding setting of property values.
SpEL also supports nested properties by using the standard dot notation (such as
`prop1.prop2.prop3`) and also the corresponding setting of property values.
Public fields may also be accessed.
The following example shows how to use dot notation to get the length of a literal:
[source,java,indent=0]
[subs="verbatim,quotes"]
----
@@ -287,22 +288,21 @@ It is also possible to configure the behaviour of the SpEL expression compiler.
=== SpEL compilation
Spring Framework 4.1 includes a basic expression compiler. Expressions are usually
interpreted which provides a lot of dynamic flexibility during evaluation but
does not provide optimum performance. For occasional expression usage
this is fine, but when used by other components like Spring Integration,
performance can be very important and there is no real need for the dynamism.
interpreted, which provides a lot of dynamic flexibility during evaluation but
does not provide optimum performance. For occasional expression usage,
this is fine, but, when used by other components such as Spring Integration,
performance can be very important, and there is no real need for the dynamism.
The SpEL compiler is intended to address this need. The compiler will generate a
real Java class on the fly during evaluation that embodies the expression behavior
and use that to achieve much faster expression evaluation. Due to the lack of
typing around expressions the compiler uses information gathered during the
interpreted evaluations of an expression when performing compilation. For example,
it does not know the type of a property reference purely from the expression but
during the first interpreted evaluation it will find out what it is. Of course,
basing the compilation on this information could cause trouble later if the types
of the various expression elements change over time. For this reason compilation
is best suited to expressions whose type information is not going to change on
repeated evaluations.
The SpEL compiler is intended to address this need. During evaluation, the compiler
generates a Java class that embodies the expression behavior at runtime and uses that
class to achieve much faster expression evaluation. Due to the lack of typing around
expressions, the compiler uses information gathered during the interpreted evaluations
of an expression when performing compilation. For example, it does not know the type
of a property reference purely from the expression, but during the first interpreted
evaluation, it finds out what it is. Of course, basing compilation on such derived
information can cause trouble later if the types of the various expression elements
change over time. For this reason, compilation is best suited to expressions whose
type information is not going to change on repeated evaluations.
For a basic expression like this:
@@ -360,24 +360,24 @@ After selecting a mode, use the `SpelParserConfiguration` to configure the parse
Object payload = expr.getValue(message);
----
When specifying the compiler mode it is also possible to specify a classloader (passing null is allowed).
Compiled expressions will be defined in a child classloader created under any that is supplied.
It is important to ensure if a classloader is specified it can see all the types involved in
the expression evaluation process. If none is specified then a default classloader will be used
When you specify the compiler mode, you can also specify a classloader (passing null is allowed).
Compiled expressions are defined in a child classloader created under any that is supplied.
It is important to ensure that, if a classloader is specified, it can see all the types involved in
the expression evaluation process. If you do not specify a classloader, a default classloader is used
(typically the context classloader for the thread that is running during expression evaluation).
The second way to configure the compiler is for use when SpEL is embedded inside some other
component and it may not be possible to configure via a configuration object. In these cases
it is possible to use a system property. The property `spring.expression.compiler.mode` can be
set to one of the `SpelCompilerMode` enum values (`off`, `immediate`, or `mixed`).
component and it may not be possible to configure it through a configuration object. In these
cases, it is possible to use a system property. You can set the `spring.expression.compiler.mode`
property to one of the `SpelCompilerMode` enum values (`off`, `immediate`, or `mixed`).
[[expressions-compiler-limitations]]
==== Compiler limitations
Since Spring Framework 4.1 the basic compilation framework is in place. However, the framework
Since Spring Framework 4.1, the basic compilation framework is in place. However, the framework
does not yet support compiling every kind of expression. The initial focus has been on the
common expressions that are likely to be used in performance critical contexts. The following
common expressions that are likely to be used in performance-critical contexts. The following
kinds of expression cannot be compiled at the moment:
- expressions involving assignment