This site contains the documentation that is relevant to older WSO2 product versions and offerings.
For the latest WSO2 documentation, visit https://wso2.com/documentation/.

Configuring Request Context

Owned by Former user (Deleted)
Last updated: Oct 16, 2012Version comment
3 min read

Per each request made to the registry, a Handler Manager decides whether the call will be intercepted through one or more handlers before it being served by the registry itself. For a given method implemented by the registry, the Handler Manager stores a dictionary of filters and associated handlers.

If a filter evaluates to true, the associated handler will be invoked. Soon after the handler being invoked, the call will be returned to the handler manager, which evaluates whether the request has been completely served by the handler. If the handler has not completely served the request, the handler manager will poll the remaining filters to determine whether any downstream handlers need to be invoked. This process will continue until the handler manager is being told that a handler completely served the request or until there are no more filters to poll.

In order to facilitate the ability for more than one handler to act upon a resource or collection, and also pass information downstream, a request context is passed to each handler operation. It contains a number of methods through which you can extract data from the request and also add information to. If a handler decides that it has completely served a request and no downstream handlers should be invoked, it can set the ProcessingComplete flag.

requestContext.setProcessingComplete(true)

This will cause the downstream handlers to not be invoked. Also, in such a situation, the registry implementation can decide, based on the result returned by the handler chain to whether it should continue processing or simply return. Therefore, the request context serves as the basis for handler-handler and handler-registry communication and plays a vital role in the process of extending the registry.

There is the listing of the RequestContext class below (only the Accessors are shown here).

Let's go through some of the interesting details provided in the RequestContext.

  • resourcePath - Is a unique path used to refer to the resource related to the current request.
  • Resource attribute - Contains the actual resource instance targeted by the request. This could be null for certain operations. Therefore, it is recommended to do a null check, prior to accessing the attribute.
  • sourceURL - Contains valid value only for the import operation. It provides the URL to import resource content.
  • parentPath and parentCollection - Are the path and the collection implementation of the parent resource respectively. It also provides a properties attribute to store handler specific information if necessary.
  • registry, repository and versionRepository attributes - Contain references to the Registry, Repository and VersionRepository instances of the current Registry. These instances can be used to perform various operations, both related to resources and others, within the handler.
  • processingComplete field - It is possible to chain handlers in the Registry by configuring them to engage for the same criteria. Therefore, Registry will keep on executing other matching handlers, although processing has been already done by one handler.

    Note

    This behavior is not recommended and may cause undesirable effects if not used with extreme care. Therefore, it is highly recommended to configure only one handler per request and set the processingComplete field to true to terminate the processing after the handler is invoked.