...

Filters

Often it's necessary to pre- or post-process some requests according to a number of requirements.
For example, a request like

...

ContainerRequestFilters with a @PreMatching annotation are run before the JAX-RS resource selection process starts. PreMatching filters should be used to modify request URI , or headers or input stream. Post-matching filters are run just before a selected resource method is executed.

Multiple ContainerRequestFilter and ContainerResponseFilter filters can be ordered using a @Priority annotation.

The implementations can be registered like any other types type of providers :

<beans>
    <jaxrs:server id="customerService" address="/">
        <jaxrs:serviceBeans>
            <bean class="org.CustomerService" />
        </jaxrs:serviceBeans>

        <jaxrs:providers>
            <ref bean="authorizationFilter" />
        </jaxrs:providers>
        <bean id="authorizationFilter" class="com.bar.providers.AuthorizationContainerRequestFilter">
            <!-- authorization bean properties -->
        </bean>
    </jaxrs:server>
</beans>

Difference between JAXRS filters and CXF interceptors

...

Sometimes you may want to use CXF interceptors rather than writing JAXRS filters. For example, suppose you combine JAXWS and JAXRS and you need to log only inbound or outbound messages. You can reuse the existing CXF interceptors :

<beans>
    <bean id="logInbound" class="org.apache.cxf.interceptor.LoggingInInterceptor"/>
    <bean id="logOutbound" class="org.apache.cxf.interceptor.LoggingOutInterceptor"/>

    <jaxrs:server> 
        <jaxrs:inInterceptors>
            <ref bean="logInbound"/>
        </jaxrs:inInterceptors>
        <jaxrs:outInterceptors>
            <ref bean="logOutbound"/>
        </jaxrs:outInterceptors>
    </jaxrs:server>

    <jaxws:endpoint>
        <jaxws:inInterceptors>
            <ref bean="logInbound"/>
        </jaxws:inInterceptors>
        <jaxws:outInterceptors>
            <ref bean="logOutbound"/>
        </jaxws:outInterceptors>
    </jaxws:endpoint>

</beans>

...

Using filters and interceptors makes it possible to override all the needed request/response properties.

Overriding HTTP method

Register Use @PreMatching ContainerRequestFilter or register a custom RequestHandler CXF in intrerceptor filter which will replace the current method value keyed by
Message.HTTP_REQUEST_METHOD in a given Message.

...

One can do it either from a @PreMatching ContainerRequestFilter or CXF input interceptor (registered at the early phase like USER_STREAM) or from a RequestHandler filter, for example :

String s = m.get(Message.REQUEST_URI);
s += "/data/";
m.put(Message.REQUEST_URI, s);

...

It is assumed here a user prefers not to use explicit Response objects in the application code.
This can be done either from a ContainerResponseFilter or CXF output interceptor (phase like MARSHALL will do) or from a ResponseHandler filter, for example this code will work for both JAXRS and JAXWS :

...

In some cases you may want to have a JAXRS Response entity which a given RequestHandler or ResponseHandler filter has produced to be directly written to the output stream. For example, a CXF JAXRS WADLGenerator RequestHandler filter produces an XML content which does not have to be serialized by JAXRS MessageBodyWriters. If you do need to have the writers ignored then set the following property on the current exchange in the custom handler :

...

Custom invokers can be registered like this :

<beans>

    <jaxrs:server address="/"> 
        <jaxrs:invoker>
            <bean class="org.apache.cxf.systest.jaxrs.CustomJAXRSInvoker"/>
        </jaxrs:invoker>
    </jaxrs:server>

</beans>