Configuring Filters

Each handler is associated with a filter. Filters provide criteria for engaging handlers. Registry always evaluates the associated filter before invoking a handler. If the filter evaluates to true, it will invoke its associated handler.

All filters should extend from an abstract class named Filter. The  implementations of Filter should provide criteria for all handler methods by overwriting corresponding Filter method. There is the listing of Filter class below.

For example, there is a handler "H1" and filter "F1" associated with it.

• If "H1" is configured for the GET method, Registry will first invoke the handleGet(...) method of "F1." If it returns true, Registry will invoke the get(...) method of "H1."

• If F1.handleGet(...) evaluates to false, Registry will not invoke H1.get(...).

The RequestContext instance containing information about the current request is passed in to all methods of Filter. Filter implementations can access these information when deciding whether or not to engage its associated handler. Two built-in Filter implementations for most common filtering scenarios are shipped with the Registry:

• MediaTypeMatcher - Filters are based on the Media type of the resource. For more information about Media types see Adding a Resource.
• URLMatcher - Evaluates to true, if the current resource path matches with a preconfigured regular expression.

MediaTypeMatcher

This filter will determine whether a given handler is invoked based on the Media type of the resource (or collection) on which the registry operation is performed. Configuration of a Media type Matcher includes a single Media type for which a handler baring this filter will be executed.

<filter class="org.wso2.carbon.registry.core.jdbc.handlers.filters.MediaTypeMatcher">
    <property name="mediaType">application/xml</property>
</filter>

The definition above ensures that the handler in concern is executed against all XML files.

URLMatcher

This filter can be used to invoke handlers based on the path of the resource (or collection) on which the registry operation is performed. Unlike the Media Type Matcher, the URL Matcher allows you to configure the target resource path per registry operation. The accepted value is a regular expression and therefore, can easily be written to match more than one resource (or collection) stored on the repository. The configuration for a URL Matcher can have one or more properties, as follows:

<filter class="org.wso2.carbon.registry.core.jdbc.handlers.filters.URLMatcher">
    <property name="putPattern">/a/b/.*</property>
</filter>

The definition above ensures that the handler in concern is executed against all the resource within the collection /a/b/. This includes children as well as grand children. You can have more than one such pattern property.

<filter class="org.wso2.carbon.registry.core.jdbc.handlers.filters.URLMatcher">
    <property name="putPattern">/a/b/.*</property>
    <property name="getPattern">/a/.*</property>
</filter>

The URL Matcher defines a list of possible properties that can used. See the picture above.

Support for Inverse Operations

WSO2 Governance Registry also supports inversion of filter operations. This can be done by setting the invert property to true.

<filter class="org.wso2.carbon.registry.core.jdbc.handlers.filters.URLMatcher">
    <property name="putPattern">/a/b/.*</property>
    <property name="invert">true</property>
</filter>

Setting this property for a Media Type Matcher will cause the handler to execute for all other Media types than the specified. Setting this property for a URL Matcher will cause the handler to execute for each operation configured using the pattern property but for all paths that do not match the given regular expression.