Feedback wanted: Allowing policies to modify PolicyFailures emitted by *other* policies in chain
by Marc Savy
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.
5 years, 9 months
Bug in Vert.x Gateway was preventing plugins being loading from static config
by Marc Savy
This might only hit more advanced users, but I discovered that on the
Vert.x Gateway that plugins were not being loaded from the static
config (conf.json).
This is distinct from any policy plugin stuff.
For example, if you had your request-parser loaded from a custom plugin:
"request-parser": {
"class": "plugin:io.apiman.plugins:custom-path-parser-plugin-demo:1.4.2.Final:war/io.apiman.plugins.demo.custompathparser.CustomPathParserImpl",
"config": {
"defaultOrgName": "Apiman"
}
}
This would fail to work properly. I've fixed it now, and shall do a
1.4.2.Final release shortly unless some problems pop up.
Please do try it out on master if this is a feature you use.
I have been drafting up a blog post showing how to write your own path
parser implementation (so you can have custom URL patterns on your
Apiman Gateway). So, watch out for that one!
Regards,
Marc
5 years, 10 months
Is it possible blocking request after request body parsing?
by 林 柏廷
Hi all,
I would like to customize a policy, which parses the request body and blocks the request in case.
in http://www.apiman.io/latest/developer-guide.html 4.2.1.2 IData policy, it describes:
The request or response body will not begin streaming before the corresponding doApply has been called, however, it is still possible to interrupt the conversation during the streaming phase by signalling doFailure or doError.
When I trace the transformation-policy source code, doApply() executes before getRequestDataHandler() which matches the description.
In doApply() I can blocks the request via chain.doFailure() however I have no idea how to interrupt/block request in getRequestDataHandler().
Besides, I found following mail group which is similar to my question.
Eric also points it's possible to parse the body before apply in request:
On Thu, Feb 2, 2017 at 10:31 PM, Eric Wittmann <
eric.wittmann at redhat.com> wrote:
The bottom line here is that you cannot return a Policy Failure (or
customize it) based on information in the response body. The response is
streamed from the back-end to the client, and at the time streaming begins,
the response code and HTTP headers have already been sent.
It sounds to me like you're asking for a feature where you can parse
the response body *before* the policy's "apply" method is invoked. we have
such a feature for requests, but not for responses. I suspect core changes
to apiman would be required to enable that. It seems like a reasonable
request to me, as long as users of the feature understand the performance
and memory requirements of enabling it.
-Eric
Thanks for any comments in advance.
Kind Regards
BT
5 years, 10 months
Preparing for release 1.4.0
by Marc Savy
Hi,
We're now preparing for the release of 1.4.0.Final. Expect a release
in the coming days. The predominant change is the move from
Elasticsearch 1.x to Elasticsearch 5.x.
Please test out master if you can. Especially if you use ES for the
Apiman Manager.
There are also a few other bug-fixes and few bits that will make it
into this release.
Thanks to everyone who has contributed!
Regards,
Marc
5 years, 10 months
Help needed: Feedback/testing for Apiman on ES 5.x (and possibly ES 2.x)
by Marc Savy
Hi,
After spending the last week or more fiddling with test harness and CI
issues, we finally seem to be (almost) there.
I'd appreciate anyone who could test the latest an ES 5.x version of
Apiman for me. It still needs some tidying up, but should be
functional.
Steps:
git clone git@github.com:msavy/apiman.git
git checkout es5x
mvn clean install
cd distro/{distro of your choice}/target/{distro overlay zip of your choice}
handle the distro zip as you usually would a release (i.e. extract
overlay onto a server such as wildfly10)
Please modify apiman.properties to match your particular configuration
and try things out!
Regards,
Marc
5 years, 10 months
