As I had no negative feedback, this has been merged (along with
tests). It should be in the next release.
On 4 July 2018 at 20:44, Marc Savy <marc.savy(a)redhat.com> wrote:
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.