Class SimpleEvaluationContext

All Implemented Interfaces:

public final class SimpleEvaluationContext extends Object implements EvaluationContext
A basic implementation of EvaluationContext that focuses on a subset of essential SpEL features and customization options, targeting simple condition evaluation and in particular data binding scenarios.

In many cases, the full extent of the SpEL language is not required and should be meaningfully restricted. Examples include but are not limited to data binding expressions, property-based filters, and others. To that effect, SimpleEvaluationContext is tailored to support only a subset of the SpEL language syntax, e.g. excluding references to Java types, constructors, and bean references.

When creating a SimpleEvaluationContext you need to choose the level of support that you need for property access in SpEL expressions:

  • A custom PropertyAccessor (typically not reflection-based), potentially combined with a DataBindingPropertyAccessor
  • Data binding properties for read-only access
  • Data binding properties for read and write

Conveniently, forReadOnlyDataBinding() enables read access to properties via DataBindingPropertyAccessor; same for forReadWriteDataBinding() when write access is needed as well. Alternatively, configure custom accessors via forPropertyAccessors(org.springframework.expression.PropertyAccessor...), and potentially activate method resolution and/or a type converter through the builder.

Note that SimpleEvaluationContext is typically not configured with a default root object. Instead it is meant to be created once and used repeatedly through getValue calls on a pre-compiled Expression with both an EvaluationContext and a root object as arguments: Expression.getValue(EvaluationContext, Object).

In addition to support for setting and looking up variables as defined in the EvaluationContext API, SimpleEvaluationContext also provides support for registering and looking up functions as variables. Since functions share a common namespace with the variables in this evaluation context, care must be taken to ensure that function names and variable names do not overlap.

For more power and flexibility, in particular for internal configuration scenarios, consider using StandardEvaluationContext instead.

Rossen Stoyanchev, Juergen Hoeller, Sam Brannen
See Also: