Event Listener module
Job module
Language module
Macro Module
Servlet Filter module
Servlet module
Theme module
Web UI modules
Workflow module

Servlet Filter module


Confluence 2.10 and later

Purpose of this module type

Using Servlet Filter plugin modules you can deploy Java Servlet filters as a part of your plugin, specifying the location and ordering of your filter. In this way you can build filters that can tackle tasks like profiling, monitoring, and content generation.


The root element for the Servlet Filter plugin module is servlet-filter. To configure it, use the following attributes and child elements.





The class which implements this plugin module. The class you need to provide depends on the module type. For example, Confluence theme, layout and colour-scheme modules can use classes already provided in Confluence. So you can write a theme-plugin without any Java code. But for macro and listener modules you need to write your own implementing class and include it in your plugin. See the plugin framework guide to creating plugin module instances.

The servlet filter Java class must implement javax.servlet.Filter.



Indicate whether the plugin module should be disabled (value='disabled') or enabled by default (value='enabled').

Default: enabled.


The localization key for the human-readable name of the plugin module.


The unique identifier of the plugin module. You refer to this key to use the resource from other contexts in your plugin, such as from the plugin Java code or JavaScript resources.
<servlet-filter key="helloWorld">
I.e. the identifier of the servlet filter.

The position of the filter in the application filter chain.

If two plugins provide filters at the same position, the 'weight' attribute (see later) is evaluated.

  • after-encoding – Near the very top of the filter chain in the application, but after any filters that ensure the integrity of the request.
  • before-login – Before the filter that logs in the user with any authentication information included in the request.
  • before-decoration – Before the filter that does decoration of the response, typically with Sitemesh.
  • before-dispatch – At the end of the filter chain, before any servlet or the filter that handles the request by default.

Default: before-dispatch.


The human-readable name of the plugin module. 

i.e. the human-readable name of the filter.

Default: the plugin key.


Indicates whether this plugin module is a system plugin module (value='true') or not (value='false'). Only available for non-OSGi plugins.

Default: false.


The weight of the filter, used to decide in which order to place the filter in the chain of filters that have the same 'location' attribute specified (see previously).

The higher weight, the lower the filter's position.

Default: 100.

Attributes marked with * are required.





The description of the plugin module. The 'key' attribute can be specified to declare a localization key for the value instead of text in the element body. i.e. the description of the filter.



Initialization parameters for the filter, specified using param-name and param-value sub-elements, just as in web.xml.

This element and its child elements may be repeated.


A resource for this plugin module. This element may be repeated. A 'resource' is a non-Java file that a plugin may need in order to operate. Refer to Adding Resources to your Project for details on defining a resource.


The pattern of the URL to match. This element may be repeated.

The URL pattern format is used in Atlassian plugin types to map them to URLs. On the whole, the pattern rules are consistent with those defined in the Servlet 2.3 API. The following wildcards are supported:

  • * matches zero or many characters, including directory slashes.
  • ? matches zero or one character.
  • /mydir/* matches /mydir/myfile.xml
  • /*/admin/*.??ml matches /mydir/otherdir/admin/myfile.html

Determines when the filter is triggered. You can include multiple dispatcher elements.
If this element is present, its content must be one of the following, corresponding to the filter dispatcher options defined in the Java Servlet 2.4 specification:

  • REQUEST – the filter applies to requests that came directly from the client.
  • INCLUDE – the filter applies to server-side includes done via RequestDispatcher.include().
  • FORWARD – the filter applies to requests that are forwarded via RequestDispatcher.forward().
  • ERROR – the filter applies to requests that are handled by an error page.

Note: This element is only available in Plugin Framework 2.5 and later.
If this element is not present, the default is REQUEST. (This is also the behavior for Plugin Framework releases earlier than 2.5.)

Default: filter will be triggered only for requests from the client.

Elements marked with * are required.

Example of Servlet Filter plugin module

Here is a sample atlassian-plugin.xml file containing a single Servlet Filter:

<atlassian-plugin name="Hello World Filter" key="example.plugin.helloworld" plugins-version="2">
        <description>A basic Servlet filter module test - says "Hello World!</description>
        <vendor name="Atlassian Software Systems" url="http://www.atlassian.com"/>

    <servlet-filter name="Hello World Servlet" key="helloWorld" class="com.example.myplugins.helloworld.HelloWorldFilter" location="before-dispatch" weight="200">
        <description>Says Hello World, Australia or your name.</description>

Accessing your Servlet Filter

You can access your servlet in the Atlassian web application via each url-pattern you specify. But, unlike the Servlet plugin module, the url-pattern is relative to the root of the web application.

For example, if you specify a url-pattern of /helloworld as previously, and your Atlassian application is deployed at yourserver/contextpath -- then your servlet filter would be accessed at yourserver/contextpath/helloworld.


Here is some information you need to know when developing or configuring a Servlet Filter plugin module:

  • Servlet filter init() method is not called on web application start as for a normal filter. Instead, this method is called the first time your filter is accessed after each time plugin module is enabled. This means that if you disable a plugin containing a filter or a single Servlet Filter module and re-enable it again, the filter is re-created and its init() method is called again.
  • Because servlet filters are deployed beneath root, be careful when choosing each url-pattern under which your filter is deployed. If you plan to handle the request in the filter, it is recommended to use a value that will always be unique to the world.
  • Some application servers, like WebSphere 6.1, don't call servlet filters if there is no underlying servlet to match the URL. On these systems, you will only be able to create a filter to handle normal application URLs.

Rate this page: