From marc.savy at redhat.com Tue Jul 3 10:59:51 2018 From: marc.savy at redhat.com (Marc Savy) Date: Tue, 3 Jul 2018 15:59:51 +0100 Subject: [Apiman-user] 1.4.3.Final is out! Message-ID: A couple of bugs fixed, including the Vert.x Gateway being unable to load plugins from its static config. Thanks for your contributions, everyone! http://www.apiman.io/blog/apiman/release/2018/07/03/release-1.4.3.html Regards, Marc p.s. We released 1.4.2.Final but due to my release VM having some kind of time issues (it was stuck on 28th June!) we immediately released 1.4.3.Final to ensure accurate metadata. From marc.savy at redhat.com Tue Jul 3 11:01:23 2018 From: marc.savy at redhat.com (Marc Savy) Date: Tue, 3 Jul 2018 16:01:23 +0100 Subject: [Apiman-user] Blog: Customising path patterns for your Apiman Gateway Message-ID: =After having a couple of requests on the topic of customising Apiman Gateway paths, I thought I'd write a blog: http://www.apiman.io/blog/apiman/gateway/manager/plugin/extensibility/2018/07/03/custom-url-parser.html This same concept works for plugins all throughout Apiman. Regards, Marc From marc.savy at redhat.com Wed Jul 4 15:44:35 2018 From: marc.savy at redhat.com (Marc Savy) Date: Wed, 4 Jul 2018 20:44:35 +0100 Subject: [Apiman-user] Feedback wanted: Allowing policies to modify PolicyFailures emitted by *other* policies in chain In-Reply-To: References: Message-ID: 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 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. From marc.savy at redhat.com Sun Jul 8 15:13:01 2018 From: marc.savy at redhat.com (Marc Savy) Date: Sun, 8 Jul 2018 20:13:01 +0100 Subject: [Apiman-user] Feedback wanted: Allowing policies to modify PolicyFailures emitted by *other* policies in chain In-Reply-To: References: Message-ID: 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 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 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. From marc.savy at redhat.com Sat Jul 14 07:15:54 2018 From: marc.savy at redhat.com (Marc Savy) Date: Sat, 14 Jul 2018 12:15:54 +0100 Subject: [Apiman-user] Feedback wanted: Allowing policies to modify PolicyFailures emitted by *other* policies in chain In-Reply-To: References: Message-ID: 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 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 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 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 From marc.savy at redhat.com Wed Jul 25 12:11:25 2018 From: marc.savy at redhat.com (Marc Savy) Date: Wed, 25 Jul 2018 17:11:25 +0100 Subject: [Apiman-user] Apiman 1.5 released Message-ID: Hi All, Apiman 1.5 has been released. It contains an important new policy feature: the ability to modify policy failures before they are returned to users. 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). Blog post soon! Vert.x (Gateway Only): http://downloads.jboss.org/apiman/1.5.0.Final/apiman-distro-vertx-1.5.0.Final.zip WF10/EAP7.1: http://downloads.jboss.org/apiman/1.5.0.Final/apiman-distro-wildfly10-1.5.0.Final-overlay.zip WF11: http://downloads.jboss.org/apiman/1.5.0.Final/apiman-distro-wildfly11-1.5.0.Final-overlay.zip EAP7: http://downloads.jboss.org/apiman/1.5.0.Final/apiman-distro-eap7-1.5.0.Final-overlay.zip Tomcat 8+: http://downloads.jboss.org/apiman/1.5.0.Final/apiman-distro-tomcat8-1.5.0.Final-overlay.zip Regards, Marc From marc.savy at redhat.com Fri Jul 27 05:33:00 2018 From: marc.savy at redhat.com (Marc Savy) Date: Fri, 27 Jul 2018 10:33:00 +0100 Subject: [Apiman-user] Apiman 1.5 released In-Reply-To: References: Message-ID: Yet again we seem to have had a problem with the date on the release machine (claiming it was still 4th July). So I'll be doing a 1.5.1.Final release to ensure all metadata is correct. Sorry about that. I'll try to add safeguards to ensure it doesn't happen again. On 25 July 2018 at 17:11, Marc Savy wrote: > Hi All, > > Apiman 1.5 has been released. > > It contains an important new policy feature: the ability to modify > policy failures before they are returned to users. 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). > > Blog post soon! > > Vert.x (Gateway Only): > http://downloads.jboss.org/apiman/1.5.0.Final/apiman-distro-vertx-1.5.0.Final.zip > > WF10/EAP7.1: > http://downloads.jboss.org/apiman/1.5.0.Final/apiman-distro-wildfly10-1.5.0.Final-overlay.zip > > WF11: > http://downloads.jboss.org/apiman/1.5.0.Final/apiman-distro-wildfly11-1.5.0.Final-overlay.zip > > EAP7: > http://downloads.jboss.org/apiman/1.5.0.Final/apiman-distro-eap7-1.5.0.Final-overlay.zip > > Tomcat 8+: > http://downloads.jboss.org/apiman/1.5.0.Final/apiman-distro-tomcat8-1.5.0.Final-overlay.zip > > Regards, > Marc From marc.savy at redhat.com Fri Jul 27 09:47:04 2018 From: marc.savy at redhat.com (Marc Savy) Date: Fri, 27 Jul 2018 14:47:04 +0100 Subject: [Apiman-user] Apiman 1.5 released In-Reply-To: References: Message-ID: Builds with fixed date-related metadata (likely non-impactful, but we decided to be cautious) Vert.x (Gateway Only): http://downloads.jboss.org/apiman/1.5.1.Final/apiman-distro-vertx-1.5.1.Final.zip WF10/EAP7.1: http://downloads.jboss.org/apiman/1.5.1.Final/apiman-distro-wildfly10-1.5.1.Final-overlay.zip WF11: http://downloads.jboss.org/apiman/1.5.1.Final/apiman-distro-wildfly11-1.5.1.Final-overlay.zip EAP7: http://downloads.jboss.org/apiman/1.5.1.Final/apiman-distro-eap7-1.5.1.Final-overlay.zip Tomcat 8+: http://downloads.jboss.org/apiman/1.5.1.Final/apiman-distro-tomcat8-1.5.1.Final-overlay.zip On 27 July 2018 at 10:33, Marc Savy wrote: > Yet again we seem to have had a problem with the date on the release > machine (claiming it was still 4th July). So I'll be doing a > 1.5.1.Final release to ensure all metadata is correct. > > Sorry about that. I'll try to add safeguards to ensure it doesn't happen again. > > On 25 July 2018 at 17:11, Marc Savy wrote: >> Hi All, >> >> Apiman 1.5 has been released. >> >> It contains an important new policy feature: the ability to modify >> policy failures before they are returned to users. 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). >> >> Blog post soon! >> >> Vert.x (Gateway Only): >> http://downloads.jboss.org/apiman/1.5.0.Final/apiman-distro-vertx-1.5.0.Final.zip >> >> WF10/EAP7.1: >> http://downloads.jboss.org/apiman/1.5.0.Final/apiman-distro-wildfly10-1.5.0.Final-overlay.zip >> >> WF11: >> http://downloads.jboss.org/apiman/1.5.0.Final/apiman-distro-wildfly11-1.5.0.Final-overlay.zip >> >> EAP7: >> http://downloads.jboss.org/apiman/1.5.0.Final/apiman-distro-eap7-1.5.0.Final-overlay.zip >> >> Tomcat 8+: >> http://downloads.jboss.org/apiman/1.5.0.Final/apiman-distro-tomcat8-1.5.0.Final-overlay.zip >> >> Regards, >> Marc