Greetings, earthlings! On Friday of last week we released the absolute best version of apiman ever! This release has a fair number of bugs fixed, as well as a few new things. Read on for the details!
Where can I find more information?
The release notes for this release can be found here:
And of course, all of the standard sources of information have been updated:
Just give me the highlights!
Mouse clicky finger too tired? No worries, read on for some of the highlights (not the children’s magazine, but still pretty cool):
A really annoying thing about apiman, ever since version 1.0, has been the inability to delete anything. Well now you can! The following can now be deleted:
- Client Apps
Note that there are some conditions that must be met, different for each type of thing, before a delete will be successful. For example, you can only delete an API if it has no (0) published versions.
Decent Logging in the Gateway
We’re not done with this yet, but we finally have decent logging support in the Gateway. In fact, if you’re creating a custom policy, you should access the logger by getting it from the policy conext. Something like this:
IApimanLogger logger = context.getLogger(getClass()); logger.info("An INFO message here!"); logger.debug("A DEBUG message here!");
This is the best way to do logging in apiman. You probably want to stay away from standard output or a custom logger implementation within your policy.
Circuit Breaker Policy
Apiman now comes with a new Circuit Breaker policy (available as a plugin). If you’re not familiar with the circuit breaker pattern, I recommend you go here:
Plugin ClassLoader Improvements
A number of community members have been building their own custom plugins, and they’ve run into some issues with how classes and resources are loaded. In this latest version of apiman we have made a few changes (and fixed a few bugs) that should make writing a custom policy much easier. In particular, the plugin classloader was not properly loading resources from library dependencies. This meant that, for example, any third party library you used that tried to load a service via a Java ServiceLoader would fail (because the service loader’s configuration file would not be found).
Additionally, we’re now setting the plugin’s classloader as the current thread’s context classloader. This means that, again, any of those calls to ServiceLoader will be searching for resources in the correct classloader.
OK thanks, I’m out!
Thanks for reading - see you later.