OGNL replacement

This page is dedicated to replacing OGNL from all developer facing locations. The first step to tackling this is to catalog them all.

Catalog

The catalog contains all the locations that OGNL is used that developers have access to. An example of a place that OGNL is used that developers don't have access to is the processing HTTP request parameters into JavaBean properties. Here is the list:

• Struts configuration
  • Result parameters
  • Any other locations where OGNL can be used in configuration files?
• Struts taglibs for nearly all attributes
• ParameterInterceptor
• validation xml files
• default type conversion (com.opensymphony.xwork2.util.XWorkBasicConverter)
• com.opensymphony.xwork2.util.XWorkTestCaseHelper

Issues

The specific issues that need to be addressed are:

• OGNL is inconsistent and incompatible with the UEL
• Inconsistent use of %{} and ${} notation in tags vs results
• There's no evaluate now vs. evaluate later concept (UEL ${} vs #{})
• Inconsistent default evaluation in tags and results (some evaluate expression, some don't. Users have no way of knowing without checking the javadoc/code)

Goals

• Pluggable EL or simply UEL-compliant??
• @OGNLDependent annotation to place on all classes / methods / fields to indicate reliance on OGNL (useful for eventual refactoring)?