Version 1.5 of Apiman is released!

· apiman, release
Avatar for Marc Savy
Co-founder & maintainer of Apiman. Founded Black Parrot Labs to support enterprise Apiman users.
/ Black Parrot Labs /

I’m happy to announce that Apiman 1.5.1.Final is out.

It contains an important new policy feature: the ability to modify policy failures before they are returned to users (even if they are thrown by another policy).

This means that policies such as CORS can add their headers, irrespective of whether the request was successful or not (e.g. due to rate limiting).

Failure Processing

When a policy throws a failure (e.g. rate limit reached), previously this caused an immediate termination that bypassed all other policies. Failure processing was requested in the community to allow policies to modify failures emitted by other policies, such that headers can be set.

To implement this, you simply need to override the default method processFailure in IPolicy:

default void processFailure(PolicyFailure failure, IPolicyContext context, Object config,  IPolicyFailureChain chain) { ... }

Or, if you’re using AbstractMappedPolicy, then you should override doProcessFailure:

protected void doProcessFailure(PolicyFailure failure, IPolicyContext context, C config, IPolicyFailureChain chain) { ... }

For example, in the CORS plugin it simply adds the headers:

@Override
 protected void doProcessFailure(PolicyFailure failure, IPolicyContext context, CorsConfigBean config,
         IPolicyFailureChain chain) {

     CaseInsensitiveStringMultiMap corsHeaders = getResponseHeaders(context);

     if(corsHeaders != EMPTY_MAP) {
         failure.getHeaders().putAll(corsHeaders.toMap());
     }

     chain.doFailure(failure);
 }

Meaning that even if a rate limit is hit, then the headers will still be added.

If you experience any issues, please report them to us via JIRA, GitHub, or the mailing list.