The CORS plugin has been updated to use this functionality. It will also be in the next release.<br><br>On Sunday, July 8, 2018, Marc Savy <<a href="mailto:marc.savy@redhat.com">marc.savy@redhat.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">As I had no negative feedback, this has been merged (along with<br>
tests). It should be in the next release.<br>
<br>
On 4 July 2018 at 20:44, Marc Savy <<a href="mailto:marc.savy@redhat.com">marc.savy@redhat.com</a>> wrote:<br>
> Hi,<br>
><br>
> I have a prototype of this available for people to try (forgive any<br>
> scrappiness, this will be tidied before the final version is merged):<br>
><br>
> <a href="https://github.com/apiman/apiman/pull/686/files" target="_blank">https://github.com/apiman/<wbr>apiman/pull/686/files</a><br>
><br>
> It works as follows:<br>
><br>
> Let's imagine our policy chain again.<br>
> [CORS, PolicyA, PolicyB]<br>
><br>
> * If a policy failure occurs in the *request* chain, the entire<br>
> response chain will be executed (in the usual reverse order) with<br>
> #processFailure<br>
><br>
> Imagine PolicyA throws a failure on the request leg, then each of the<br>
> policies will have a chance to modify the failure object in the<br>
> following order:<br>
> [PolicyB, PolicyA, CORS]<br>
><br>
> * If a policy failure occurs during the *response* chain, then only<br>
> the remaining policies will have a chance to process the failure.<br>
><br>
> This seemed like the most sensible/practical design to me -- happy to<br>
> hear feedback, though.<br>
><br>
> Here's an example of a policy using this proposed functionality:<br>
> <a href="https://gist.github.com/msavy/b872efa7f08929d19a420ea68ec3f584" target="_blank">https://gist.github.com/msavy/<wbr>b872efa7f08929d19a420ea68ec3f5<wbr>84</a><br>
><br>
><br>
> Regards,<br>
> Marc<br>
><br>
> On 12 April 2018 at 19:42, Marc Savy <<a href="mailto:marc.savy@redhat.com">marc.savy@redhat.com</a>> wrote:<br>
>> Marvin Oßwald filed a really interesting issue:<br>
>> <a href="https://issues.jboss.org/browse/APIMAN-1300" target="_blank">https://issues.jboss.org/<wbr>browse/APIMAN-1300</a><br>
>><br>
>> In short, if we imagine a policy chain like this:<br>
>><br>
>> [CORS, PolicyA, PolicyB]<br>
>><br>
>> Even if PolicyB emits a failure, then the CORS policy would likely<br>
>> still want to be able to process the PolicyFailure to add the relevant<br>
>> headers (otherwise a SPA type app like Angular would break).<br>
>><br>
>> This seems like a valid use-case.<br>
>><br>
>> Ideally I'd like to tackle this without breaking any existing interfaces.<br>
>><br>
>> A couple of quick ideas:<br>
>><br>
>> * Add a new interface that policies like CORS could implement that<br>
>> indicates it wants to do this kind of processing. E.g.<br>
>> IFailureProcessor or similar with a simple method signature like<br>
>> #process(PolicyFailure failureToModify).<br>
>><br>
>> * An annotation: essentially the same as above, but with a<br>
>> @WhateverWeCallIt annotation on the method that does the processing.<br>
</blockquote><br><br>-- <br>Sent from mobile phone, apologies for brevity.<br>