Re: [Apiman-dev] Feedback wanted: Allowing policies to modify PolicyFailures emitted by *other* policies in chain
Hi,
I have a prototype of this available for people to try (forgive any
scrappiness, this will be tidied before the final version is merged):
https://github.com/apiman/apiman/pull/686/files
It works as follows:
Let's imagine our policy chain again.
[CORS, PolicyA, PolicyB]
* If a policy failure occurs in the *request* chain, the entire
response chain will be executed (in the usual reverse order) with
#processFailure
Imagine PolicyA throws a failure on the request leg, then each of the
policies will have a chance to modify the failure object in the
following order:
[PolicyB, PolicyA, CORS]
* If a policy failure occurs during the *response* chain, then only
the remaining policies will have a chance to process the failure.
This seemed like the most sensible/practical design to me -- happy to
hear feedback, though.
Here's an example of a policy using this proposed functionality:
https://gist.github.com/msavy/b872efa7f08929d19a420ea68ec3f584
Regards,
Marc
On 12 April 2018 at 19:42, Marc Savy <marc.savy(a)redhat.com> wrote:
Marvin Oßwald filed a really interesting issue:
https://issues.jboss.org/browse/APIMAN-1300
In short, if we imagine a policy chain like this:
[CORS, PolicyA, PolicyB]
Even if PolicyB emits a failure, then the CORS policy would likely
still want to be able to process the PolicyFailure to add the relevant
headers (otherwise a SPA type app like Angular would break).
This seems like a valid use-case.
Ideally I'd like to tackle this without breaking any existing interfaces.
A couple of quick ideas:
* Add a new interface that policies like CORS could implement that
indicates it wants to do this kind of processing. E.g.
IFailureProcessor or similar with a simple method signature like
#process(PolicyFailure failureToModify).
* An annotation: essentially the same as above, but with a
@WhateverWeCallIt annotation on the method that does the processing.