I setup an open proxy by mistake, and used iptables to filter out rogue connections
Once upon a time, a very long ago now, about last Friday, I was provisioning some new VM images kindly provided to me by our infrastructure team. Apparently I have my own dedicated ESX server (admittedly running on some old hardware they had lying around) with which to play around to my heart’s content. That environment is intended to be a replacement for this server; but truth be told I haven’t had time to migrate all the services running on this machine over. In fact I’m currently having trouble making hudson run the unit tests.
Anyway, I was in a rush and setup mod_ajp_proxy/tomcat on the box without really thinking about what I was doing. To cut a long story short, I missed off the most important line in the proxy configuration Deny From All which meant that effectively this box was operating as an open proxy.
Setting up the adapter to use both XSLT 1.0 and 2.0 in the same JVM
At the moment, for legacy reasons, the adapter ships with Xalan as the XSLT transformation engine. There are still a lot of stylesheets out that that won’t work with XSLT 2.0. If your environment is XSLT2.0 only then our recommendation has always been to switch the default transformer factory to something like Saxon using the appropriate JVM system property on the commandline : -Djavax.xml.transform.TransformerFactory=net.sf.saxon.TransformerFactoryImpl but this makes all the transforms use saxon as the XSLT processing engine.
What if you wanted to use Saxon and it’s XSLT 2.0 engine on a per transform basis?
This week I had the first real use case for embedding a script inside an adapter workflow. In one particular instance we were actually receiving EDI files that were terminated by an odd character; od and hexdump thought it was \0205 (0x85) but when we read the file in using a java test stub it turned out to be 0xffffff85 which was annoying to say the least.
We can turn it into 0x85 by doing a classic & 0xFF, but you can’t do that terribly easily within the adapter, so this is a perfect chance for us to use [jruby]!
Setting up the adapter for multiple ways of handling errors
As we all know error handling within the adapter can be configured at the workflow, channel or adapter level. Most of the time we just write the original file out to something that can’t fail (well, unlikely to fail in the context of things) like the file system.
You care about being compliant with various regulatory regimes that say you can’t ever remember private 172.16.x.x IP addresses and say them out loud (or write them down); and yet they will happily use Winzip to password protect a zip file with an easy to remember password (sometimes to maintain “compatibility” they use encryption that can be extracted by earlier versions).