This proposal will most likely be superceded by the Ti proposal and the release of Struts Action 2.0, but should be retained for future reference.

Jericho is a whiteboard proposal describing one possible implementation of Struts 2.x. Since Struts 2.x is slated as a "revolution", the Apache practice is to assign a codename to a proposal until the Community comes to a consensus. This proposal is called "Jericho" since it tries to tear-down the walls within the Struts architecture.

General Description, Thoughts & Ideas

Jericho proposes to open-up Struts by:

  • Declaring interfaces for all core components.
  • Providing working base implementations for all core components.
  • Encapsulating all path references within "Location" objects (aka ActionForwards) and referring only to Locations from all other objects.
  • Providing additional extension points from core components so that the "Inversion of Control" pattern is fully realized. (e.g., a populate method for the FormHandler.)
  • Providing "POJO" signatures that encapsulate servlet/portlet/soap behavior so that applications can be freed of servlet/portlet/soap semantics, if so desired. This strategy would also be applied to optional packages like Validator and Tiles.
  • Retain optional access to servlet/portlet objects so that applications can be free to do whatever they need to do.

Backward compatibility

Jericho is a revolution and backward compatibility with prior versions of Struts is not the prime consideration. However, care is being taken to create a clear migration path, where practical, so that Jericho is available to the widest community possible.

Taglibs/Tools

JSP taglibs and other presentation tools will be packaged separately from the core controller classes. Tags and tools can access the framework through a StrutsContext object passed through the request, rather than searching through the servlet or portlet contexts.

ActionForms/Actions, et al

New implementations of Struts 1.x base classes will be provided. These classes will provide the Struts 1.x behavior, but will also implement the Jericho interfaces. (Much the same way perform was supported in Struts 1.1.)

These same techniques may be applied to provide adaptors for other frameworks, so as to make Struts Jericho available to the widest community possible.

Configuration

The Jericho Configuration builds on the best aspects of Struts 1.2. The elements are different but still similar. Our goal is to allow a tool, such as a XLST processor, to migrate a Struts 1.2 DTD to Struts Jericho.

A second alternative might be to provide an alternate configuration loader that would map the Struts 1.2 elements to Struts Jericho objects at initialization.

Servlet/Portlet/Soap/Mock support

Core components will implement signatures that reference a StrutsContext. Implementations of this interface can be backed by servlet, portlet, soap, or mock implementations as needed.

Also under consideration

  • Services framework. Utilize Spring IoC, HiveMind, Avalon, Pico, Cornerstone, et cetera, to configure services.
  • Configuration testing. Integrate utility of Struts TestCase, ideally configured from an XML configuration (a la Canoo Webtest).
  • Replace DTD with XML Schema.
  • Utilize protocols in resource paths. An mapped path would look like "mapping://foo" or a tiles forward would be "tiles://tilesdef". This would make it easy to plug in handlers to support different presentation engines. If no protocol is specified, the path is handled as usual.
  • Combine form-bean and validator-form configurations. A single element would allow everything Struts knows about a form to be configured in one place.
  • Integrate Tiles definitions into core configuration.
  • Adopt Struts Workflow and Struts Menu as standard options, like Validator and Tiles.
  • Utilize JodaBeans (http://www.joda.org/) as a foundation class for core components.
  • Load all configuration defaults form a core.properties file so that less is hardcoded, including a PlugIn class to bootstrap loading the core configuration.
  • Ensure that all framework objects in 2.x have consistent factory-based mechanisms to instantiate instances. (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15604)

Component Overview

Configuration registry

  • At initialization, each request adapter (servlet, filter, et cetera), adds its configuration to a single registry at a global location under a unique key.

Command Context

  • Extends CoR Context to encapsulate framework members needed to process request and render response.

Request Adapter (servlet module, portlet, SOAP, mock)

  • Receives request from container (or TestRunner)
  • Normalizes request path (masks pattern registered with container)
  • Creates context to wrap request and response objects
  • Adds reference to its configuration (stored in global registry)
  • Invokes Controller
  • When control returns, dispatches to Location (if any)

Controller

  • Receives context and selects the matching mapping
  • Adds reference to mapping instance to context
  • Sets mapping's default Location to context
  • Removes any expired messages from context
  • Invokes processor for mapping

Processor

  • Invokes series of methods ("Chain of Commands") to handle request. The default series includes:
    • Multipart
    • Locale
    • ContentType
    • NoCache
    • PreProcess
    • Roles
    • InputHandler
      • Cancel
      • Reset
      • Populate
      • Validate
      • Invalid
    • MappingHandler
      • Command | Script
        • Invoke business logic
        • Affect context state
        • Identify resource to render response
      • Location
        • Identify resource to render response

ExceptionHandler

  • Intercept any Exception thrown by Processor and set Location to designated error page.

Tags/Tools

  • Reference Command Context (stored in request) to access framework members.

Server Pages

  • Utilize tags and tools to render dynamic data.
  • No labels