Requestors: Servlet Chaining

If Morphis is running on a Servlet engine supporting Servlet chaining (like WebSphere, or Resin), then the resulting data from a Servlet or Java Server Page may be run directly through the translation process without having to perform a network call. This model is slightly different than the URL Requestor since the point of entry will be your Servlet or JSP, and not Morphis. Morphis processing is usually triggered by a mapping of mime-type to Servlet name. The Morphis servlet org.morphis.DispatchChainServlet should be used to trigger the processing.

The org.morphis.DispatchChainServlet will still use the requesting URI and the dispatch.xml file and to find a matching context. Once found, the output stream from the source Servlet or JSP is fed directly into the translation process.

This requestor paradim is quite different than the others since your Servlet or JSP is processed before Morphis handles the request. Therefore, there is effectively no requestor (however, there needs to be a mime-type mapping to trigger org.morphis.DispatchChainServlet). The following example illustrates how dispatch.xml would look.

One particular quirk with this paradigm is the abiguity surrounding headers set by the originating Servlet. Are these headers destined for the client (like the Expires: header), or are they destined for Morphis? Because of this problem, Morphis always passes the following headers through to the client: Set-Cookie, Expires, Last-Modified, and Location. Any other headers set by the originating Servlet are not explicitly passed through. Since this behavior is not standardized in the Sun servlet specification, some application server vendors may implement Servlet chaining differently, or not at all.

Additional processing instructions may be set as Servlet attributes, as headers, or as XML processing instructions in the source document. See the next section for more details.