We will now be deploying successful master builds of our all-in-one
Wildfly10 image to DockerHub. To get it:
docker pull apiman/on-wildfly10:master
As this is based on the latest commit it should not be considered
stable and is for testing, developers, advanced users, etc.
At some point in the near future we hope to have high-quality Vert.x
gateway container builds (via internal and external contributors).
More on that soon!
We've also had a lot of demand for updated OpenShift images, so it's
something we're also working on.
We've had some people using the Apiman Gateway headless for a while
now, either with the new immutable registry that loads from JSON,
or simply using any existing registry via the gateway API instead of
using a manager.
The main issue people encounter is that policy configuration contains
two fields that are difficult to work out and clumsy to encode
- `policyImpl` requires the plugin's URI, including the path to its
main class. You can work these out by looking at the plugin's source
code, but that's rather circuitous and it would be nicer to just
provide the plugin's GAV (like in the manager) and for it to be
- `policyJsonConfig` needs to be escaped properly (and must valid
according to its schema).
Neither of these aspects are especially user-friendly. My proposal is
to extend apiman-cli's functionality to allow the Apiman Gateway to be
configured directly via a YAML/JSON file (i.e. declaratively).
We can therefore provide a more user-friendly interface that automates
the resolution of plugins; validations and escapes the policy config;
A final step would be to bundle the apiman-cli tool with our distros
to make it easier to access.
 Of course, this interface was never truly designed to be used by
humans, so that's understandable
 Unfortunately named as it can be any arbitrary string, the policy
just needs to be able to decode it. For example, it could be XML.