Create a custom filter and deploying it to a proxy server

Create a custom filter for our proxy server if we need to have the proxy server perform a function, such as customized logging, that is not provided through normal product settings.

• Determine where we are going to store the artifact containing the filter we create. We can import this artifact from either a local or remote file system.

• We must know the name of the proxy server on which we want to install the custom filter.

• We must start the administrative console used to control this proxy server, it is not already started.

A filter provides an optional, secondary control over a function, that is beyond the control that is normally provided through typical product settings. For example, an applications might use a logging filter mechanism to suppress all of the events that have a particular message key.

Tasks

1. Create a custom filter.

   1. Create a class that extends com.ibm.wsspi.proxy.filter.http.HttpDefaultFilter.
   2. Override the abstract doFilter method, and, optionally, the init and destroy methods. If we override the init and destroy methods, we must call the super versions of these methods to preserve filter lifecycle functionality.
   3. Write a new doFilter method, that uses the HttpProxyServiceContext interface.

      This new doFilter method can be written such that it:

      • Changes any artifacts associated with the request or the response, such as the response itself, the response code, or the headers.

      • Changes any artifacts associated with both the request and the response.
      • Obtains information about either the request or the response.
      • Obtains information about both the request and the response.

   4. Use the proxy server filter managed bean (MBean), proxyFilterMbean, to determine the correct ordinal for the filter.

      proxyFilterMbean = AdminControl.queryNames('type=ProxyServerFilterBean,*')
      AdminControl.invoke(proxyFilterMbean, 'viewAllFilters')
      

      The order, in which all of the filters on the proxy server are processed, displays.

   5. Create the filter descriptor file, filter-context.xml

      This file is used to define all of the filters that have this descriptor. The following example illustrates a basic version of a filter-context.xml file.

      In this example. the descriptor determines where and when the given filter is run on both the request and the response. The filter point determines where the filter is run. In this example, the filter runs after the request is received. The ordinal determines when the filter gets processed relative to other filters at the same filter point. The higher the ordinal, the higher the filter is in the processing queue.

      <?xml version="1.0" encoding="UTF-8>
      <filter-context xmlns="http://www.ibm.com/2003/FilterContextSchema">
         <description>Proxy Filter Sample descriptor</description>
         <display-name>Proxy Sample Filter</display-name>
      
         <filter>
                <filter-name>HttpRequestFilter</filter-name
                <filter-class>com.ibm.ws.proxy.sample.HttpRequestFilter</filter-class>
                <description>HTTP sample filter to run at REQUEST filter point</description>
                <display-name>HTTP Request Sample</display-name>
                <protocol-name>HTTP</protocol-name>
                      <filter-point>RequestReceived</filter-point>
                <ordinal>1000</ordinal>
         </filter>
      </filter-context>
      

   6. Bundle the compiled .class files for the filter, and the filter descriptor into a JAR file.

2. Import the artifact (JAR file) containing the custom filter.

   1. In the administrative console, click...

              Applications > Application Types > Assets > Import.

   2. Select either Local file system or Remote file system to indicate where the JAR file is located.

   3. Specify the fully qualified name of the JAR file.

      The fully qualified name of the JAR file includes the directory path to where the file is located, and the file name. If we do not know the fully qualified name of the JAR file, we can use the browse function to locate the file.

3. Create a business level application (BLA) that includes this artifact.

   1. In the administrative console, click...

              Applications > New Application > New Business-level application.

   2. In the Name field, specify a name for the new application that we are creating.

      We can also specify a description of the application in the Description field.

   3. Click Apply.

4. Create a BLA composition unit (CU) from the artifact.

   1. In the Deployed assets table, click Add > Add asset.

   2. Select the name of the artifact that we imported in the first step> Continue.

   3. Change the composition unit settings as needed> Modify target.

   4. Select the proxy server on which we want to deploy this CU from the list of available deployment targets> OK.

      When we click OK the product maps the composition unit to the selected proxy server.

   5. Specify the relationship options for this composition unit.

   6. Click Finish.

   To verify that the product successfully added the CU, click Applications > Business-level applications > application_name. If the product successfully adds the CU, the name of the CU is shown in the list of deployed assets for this BLA.

5. Start the proxy server.

6. Start the BLA containing the filter.

The filter is running on the proxy server.

What to do next

Use the proxy server filter MBean, proxyFilterMbean, to verify that the filter is installed on the proxy server and that it is being processed in the correct order relative to the other filters deployed on the proxy server. To change the order in which this filter is processed, run the modifyOrdinal command against the proxyFilterMbean MBean.

Create business-level applications with the console