Import our build parent to simplify your build.gradle
We’ve standardised on gradle as our build tool of choice when developing solutions with Interlok. Since it’s possible to end up down a rabbit warren of scripting with gradle; maintaining the build script is one of key considerations, while also providing what we consider best practise when working with Interlok. As a result, we have an early preview release of our proposed parent gradle file that you can start using when developing Interlok based projects. …
Early notice about things that might break your deployments in 3.10
3.9.2 was internally named Replacement Killers and the next release currently in development also has a similarly themed name; we had a thing for Chow Yun Fat films this year… This next release is intended to be the last release in the 3.9 series, and 3.10.0 may break some existing deployments. …
You can cut and paste old config; but you probably should investigate new features
One of the things that happen when you start using Interlok for any length of time is that you end up copying old configuration, templated or otherwise; it works, there aren’t any deprecation warnings, and it gets the job done. In some cases, what we might have done previously is different to how we’d approach the problem now. A case in point is the building up of complex metadata values. …
Interlok 3.9.2 has been released and is now available for download.
A collection of services that provide PGP encryption, decryption, signing, and verification.
Interlok PGP is a collection of services that provide an easy way to perform the major PGP functions: encryption, decryption, signing, and signature verification. It uses Bouncy Castle to do the heavy lifting. …
Dynamic services have changed; plus ça change, plus c'est la même chose
In 3.8.4 we deprecated
dynamic-service-locator; this decision wasn’t taken lightly, but change and evolution is necessary so that you can get where you want to go. Originally
dynamic-service-locatorcame about so that people could make changes to configuration independently of restarting. It was only really useful if your possible configurations didn’t require new components (e.g. you always dealt in XML, and never used JSON). In fact a lot of the time it was abused by people logging to the production system and modifying config directly which wasn’t nice. Even though it’s deprecated; changing the service chain that you execute based on various things at runtime is still possible within Interlok. …
Mocking AWS interactions with localstack
One of the habits that most of our team have is to try and run everything on their local machine as much as possible to test behaviour and logic before doing any kind of deployment to something that isn’t directly within our control. It’s habit more than anything, coupled with the fact that we often do a lot of work while we’re not connected to the internet. Virtualisation, and container technologies like Docker are our best friends. …
How can I be confident that my upgrade works?
Recently I was involved in a task to test any possibly impacts updating the version of Saxon could have on the Interlok’s xslt transformation service and it got me thinking that the service tester could also be very useful when updating any mappings from xslt 1.0 to 2.0 to make sure we still get the same output. …
Interlok 3.9.1 has been released and is now available for download.
Once you're in production; what then?
Once you’ve developed your solution and deployed it then you’ll want to monitor it in production. Since all the runtime capabilities of Interlok are JMX based; our UI only uses publicly accessible JMX (there is no special sauce); you can leverage your existing JMX tools to manage Interlok. Of course the Interlok UI is perfectly capable of monitoring multiple Interlok instances which means you can use it as a monitoring tool in the absence of anything else. …