EL Context Framework Design

Motivation

In EL expressions, user and system-defined symbols can be used be used to store and retrieve values as well as point to methods that can be called. For example, the following expression references a property on some object:

#{object.property}

In JSP 2.1/Faces 1.2, the job resolving 'object' and 'property' to values that can be used in evaluating the expression is delegated to an API defined in the Unified EL specification. The root of the API is an class called 'ELContext'. Each implementer of Unified EL can create and populate one or more ELContext object for use in evaluating expressions.

This document lays out the design of a 'design-time framework' to allow tooling that supports technologies that use Unified EL. The emphasis is on supporting JSF and JSP technologies. An effort is also made to remain as backward-compatible with previous tooling as possible without shackling new design.

Restatement of Requirements

There are three major user-stakeholders in this framework. The first is Developer (specialized as JSFDeveloper for JSF tooling. Developer needs to be able to support EL at design-time any place they may use it at runtime. This user also needs a way to install additional support for dependent behaviour for things like third-party libraries.

The second stakeholder is LibraryDeveloper. LibraryDeveloper classifies any users who wishes to have a library that uses Unified EL to be supported by the tooling. In JSP an example of LibraryDeveloper is anyone creating JSP tag libraries; in JSF a specialized example is the JSFComponentLibraryDeveloper. This user needs to be able to add additional support for their library to default framework behaviour.

The third user-stakeholder is ToolsDeveloper. ToolsDeveloper uses the tooling to create specialized tooling that needs to support EL technologies. This user needs to be able to modify any default behaviour to suit specialization to the standard technologies being supporting by the tooling.

• The behavior of the framework must adapt to the version of JSF/JSP selected by JSFDeveloper for each project. The versioning is tied to the facet version in use. Projects flagged as being JSF 1.1 must continue to work as before, whereas JSF 1.2 projects must use the new behavior.

• The framework must flag illegal combinations of different J2EE runtime versions. For example, Java 1.5 or above is required for JSF 1.2. Attempting to use Java 1.4 with JSF 1.2 must be constrained by the framework.

• The framework must be flexible enough to allow each web application (as defined at design time by a dynamic web project rooted in an IProject) to have entirely different symbol resolution in different application contexts. For example, Faces 1.2 supports two different ELResolvers depending on where an expression is being resolved.

• The framework must allow third parties to modify the way symbols are resolved in each of the possible application contexts. This matches the previous requirement with respect to third party modifications but is now expanded to each application context (i.e. JSP vs. Faces).

• The framework must provide a simple but comprehensive way for JSFDeveloper to manage these new behaviors on each web application within the constraints of providing correct design time behavior. This includes managing third-party contributions and the ability to enable or disable functionality in ways that match what could happen at runtime.