Enabling the Custom JSP Filter

Implementing the custom JSP filter involves simple changes to the relevant web.xml.part fragment for your application server's WAR file.

Related Topics
In Other Guides
Installation Log Files
Using a Custom Directory for Custom JSP Pages
Avoid Overwriting Custom Pages during Upgrades

  1. Open the relevant web.xml.part fragment file in a text editor.

  2. In the custom filter section, remove the two multiline comments and make them single-line comments. You can do this by deleting the two lines having only ––>, and pasting the ––> at the end of the comment's first line.

    The custom filter section should look similar to the following, with the modified single-line comment lines shown in bold below. The following shows defined prefixes that are not defined in the web.xml.part fragment as installed.

    <!--  Custom filter -->
<!-- Custom filter class -->
      <filter>
        <filter-name>CustomFilter</filter-name>
        <filter-class>com.matrixone.servlet.CustomFilter</filter-class>
        </filter>
<!-- Custom filter definitions -->
      <filter>
        <filter-name>CustomFilter1</filter-name>
        <filter-class>com.matrixone.servlet.CustomFilter</filter-class>
        <init-param> 
            <param-name>ematrix.customFilePrefix</param-name>   
            <param-value>emxLib_</param-value>
        </init-param>
      </filter>
      <filter>
        <filter-name>CustomFilter2</filter-name>
        <filter-class>com.matrixone.servlet.CustomFilter</filter-class>
        <init-param> 
            <param-name>ematrix.customFilePrefix</param-name>   
            <param-value>emxFDA_</param-value>
        </init-param>
      </filter>
      <filter>
        <filter-name>CustomFilter3</filter-name>
        <filter-class>com.matrixone.servlet.CustomFilter</filter-class>
        <init-param> 
            <param-name>ematrix.customFilePrefix</param-name>   
            <param-value>emxUCCnet_</param-value>
        </init-param>
      </filter>
<!-- Custom filter mappings -->
      <filter-mapping>
        <filter-name>CustomFilter1</filter-name>
        <url-pattern>/common/*</url-pattern>
      </filter-mapping>
      <filter-mapping>
        <filter-name>CustomFilter2</filter-name>
        <url-pattern>/common/*</url-pattern>
      </filter-mapping>
      <filter-mapping>
        <filter-name>CustomFilter2</filter-name>
        <url-pattern>/engineeringcentral/*</url-pattern>
      </filter-mapping>
      <filter-mapping>
        <filter-name>CustomFilter3</filter-name>
        <url-pattern>/common/*</url-pattern>
      </filter-mapping>
      <filter-mapping>
        <filter-name>CustomFilter3</filter-name>
        <url-pattern>/teamcentral/*</url-pattern>
      </filter-mapping>

The above web.xml.part fragment defines three filters: CustomFilter1, CustomFilter2, and CustomFilter3. Each of these filters has its own prefix and mappings defined. All three will potentially intercept requests for pages with /common/... in their URL. The request will first be processed for CustomFilter1 and if no alternate page exists, CustomFilter2 will be used, and do on until all have been checked. If no alternate page exists for any of the defined customFilePrefixes, the originally requested resource is supplied. If an alternate page is found with any of the prefixes, that resource is supplied and checking stops. Therefore, the order in which the prefixes are defined dictates the precedende of the filters. In the example above, CustomFilter1 (emxLib_) is first, CustomFilter2 (emxFDA_) is second, CustomFilter3 (emxUCCnet_) is third, and the originally requested resource is fourth for any resource requested in the common/ directory.