[Apiman-user] Feedback wanted: Allowing policies to modify PolicyFailures emitted by *other* policies in chain

Marc Savy marc.savy at redhat.com
Sat Jul 14 07:15:54 EDT 2018


The CORS plugin has been updated to use this functionality. It will also be
in the next release.

On Sunday, July 8, 2018, Marc Savy <marc.savy at redhat.com> wrote:

> 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 at 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 at 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.
>


-- 
Sent from mobile phone, apologies for brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20180714/d405007e/attachment.html 


More information about the Apiman-user mailing list