Skip to main content
Version: 8.2405.x.x RR

DynamicConfigFilter

The DynamicConfigFilter can be used to load a filter dynamically on a running instance. The file modification will be checked in the interval configured under periodicity in the Timer section of the navajo.xml file.

Classname
ch::nevis::nevisproxy::filter::dynamic::DynamicConfigFilter
Library
libNPDynamicFilters.so.1

Configuration​

ConfigFile​

Type: string, filename with absolute path
Usage Constraints: required

The absolute path of the file where the filter configuration is located. Once the content changes, the configured filter will be reloaded. If the file is empty or contains no filter, it will be unloaded and the request continues in the chain.

ChainFromConfigBuilderClass​

Type: string
Usage Constraints: optional

Defines the class which transforms the content of the file into a filter. You should not modify the default entry.

ExpectedFilterName​

Type: string
Usage Constraints: optional

The configured filter in the 'ConfigFile' has to have the given filter-name. If the name does not match, then the filter is not loaded.

ExpectedClassName​

Type: string
Usage Constraints: optional

The configured filter in the 'ConfigFile' has to have the given filter-class. If the class name does not match, then the filter is not loaded.

Limitations​

Some filters may not be loaded dynamically. This is due to the fact that a filter may try to change the generated Apache configuration (e.g. adding Location directives) which is not possible dynamically, or register components which is only possible in the initialization phase. The following are known non-working cases with the DynamicConfigFilter:

  • IdentityCreationFilter with the ClientCert parameter
  • RewriteFilter with ModRewriteConfig parameter
  • UrlEncryptionFilter
  • CacheFilter with file based cache type

Additionally, if a given filter type is loaded only dynamically, that is, there is no other copy in the web.xml of the same filter type, it needs to also define explicitly the filter-lib parameter in its configuration, else an error with the code NVUT-005 can occur.

Example with DumpFilter​

For debugging issues, a DumpFilter may be loaded dynamically into a running nevisProxy-instance. For the filter configuration of the DumpFilter to be loaded dynamically, it has to be written into the file configured as ConfigFile in the DynamicConfigFilter. The file must exist on startup, but it can be empty. As soon as the file is modified, it is read by the DynamicConfigFilter and if the configured filter can be loaded successfully, the configured filter in the file is mapped. To remove the DumpFilter from the filter chain again, just remove its configuration from the file, so it is an empty file again.

Example configuration of the DynamicConfigFilter:

<filter>
    <filter-name>DynamicConfigFilter</filter-name>
    <filter-class>ch::nevis::nevisproxy::filter::dynamic::DynamicConfigFilter</filter-class>
    <init-param>
        <param-name>ConfigFile</param-name>
        <param-value>/var/opt/nevisproxy/default/conf/dynamic.xml</param-value>
    </init-param>
</filter>

The content of the dynamic.xml file with the dynamically loaded DumpFilter:

<filter>
    <filter-name>DumpFilter</filter-name>
    <filter-class>ch::nevis::isiweb4::filter::debug::DumpFilter</filter-class>
    <filter-lib>/opt/nevisproxy/webapp/WEB-INF/lib/libDebugFilters.so.1</filter-lib>
    <init-param>
        <param-name>DumpDirectory</param-name>
        <param-value>/var/opt/nevisproxy/default/logs</param-value>
    </init-param>
    <init-param>
        <param-name>DumpRequest</param-name>
        <param-value>both</param-value>
    </init-param>
    <init-param>
        <param-name>DumpResponse</param-name>
        <param-value>both</param-value>
    </init-param>
    <init-param>
        <param-name>MaxRequest</param-name>
        <param-value>200</param-value>
    </init-param>
</filter>

The loaded filter is mapped on the path where the DynamicConfigFilter is mapped.

Last updated on