What this is telling you is that you were able to connect but your client and the remote server were unable to find a mutually acceptable encryption algorithm to communicate over so further communication was aborted.

An easy way to tell if this is your problem as a Java/JVM client is to use the Qualys SSL analyzer and see whether it reports a Java client can connect. In my case, I saw the following failures when I entered the SSL endpoint I wanted to access:

If you happen to be a ColdFusion user, you can add -Djavax.net.debug=ssl,handshake,verbose to your jvm.config, restart and make your HTTPS request and see the full list of ciphers being attempted and the ultimate failure in your log file. My logs with the handshake_failure can be seen in this gist for comparison.

Fix with Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files

The fix is easy to implement but not easy to find. I experienced this with Oracle’s JVM and not the OpenJDK so other JVM implementations may behave differently. In the case of Oracle’s JVM, strong encryption is disabled out of the box for export reasons so the JVM can not use an encryption algorithm stronger than 128-bit. Many web servers are now disabling 128-bit SSL in favor of 256-bit and 384-bit encryption algorithms so the fix is to turn these on in your JVM.

1. Download the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files from Oracle (this link is for Java 1.8, Google for alternative JVM versions): http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html
2. Extract the two JAR files into your jre/lib/security folder overwriting the US_export_policy.jar and local_policy.jar.
3. Restart the JVM

You should now be able to connect to the remote server. If you’re still unable to connect, try enabling debugging and see which ciphers are attempted/ignored. The remote server may have an exotic configuration that requires you to contact them but the unlimited strength jurisdiction policy files should fix handshake_failure issues.

<cffunction name="extendRequestTimeoutDuringInit" output="false" access="public" returntype="any">

  <cfthread action="run" name="delayRequestTimeoutDuringInit">
    <cfset thread.adminapi = createObject("component", "cfide.adminapi.administrator") />
    <cfset thread.adminapi.login('mysecretpassword') />
    <cfset thread.runtime = createObject("component", "cfide.adminapi.runtime") />
    <cfset thread.timeout = thread.runtime.getRuntimeProperty("TimeoutRequestTimeLimit") />
    <cflog file="application" text="Extending RequestTimeout to #2*thread.timeout# seconds" />
    <cfset thread.runtime.setRuntimeProperty("TimeoutRequestTimeLimit", 2*thread.timeout) />
    <cfset sleep(2 * thread.timeout * 1000) />
    <cfset thread.runtime.setRuntimeProperty("TimeoutRequestTimeLimit", thread.timeout) />
    <cflog file="application" text="Restored RequestTimeout to #thread.timeout# seconds" />
  </cfthread>

</cffunction>

I call this in Server.cfc when my instance starts up but you could also call it from any reinit routine in OnRequestStart or OnApplicationStart. Previously when we pushed code, the first user request would kick off the initialization process while other requests queued. Many of those first requests would exceed our page timeout setting of 60 seconds. Running the above function uses a background thread to double the timeout and later reset it once the application has initialized so users no longer see timeout/error screens.

It turns out there is a bug from JDK 1.7 u75 onwards that is present at least through JDK 1.8 u60 which prevents Jstat, when run as root, from introspecting JREs running as other users.

To solve, simply run jstat as the user who owns the JRE process. You can pass the username to sudo when running jstat like:

sudo -u nobody jstat -gcutil -t <pid> 1s 30

And you’ll be treated to your output again. In my case, I have two server instances running so I like to see their output side by side at the console. Here’s my script for doing that using /usr/bin/paste and some console redirection trickery:

The username can be figured out from the process but this was a quick fix for the above bug.

docker-compose up -d

I’m simultaneously moving from a Windows machine to a Mac and I’ve been really missing the console logging for watching application activity and errors. It’s easy when installed locally to tail the coldfusion-out.log file but once containerized you don’t have that luxury (without using docker exec to log in to the running container which is a bad practice). The issue is on Linux, ColdFusion has no option to log to stdout like on Windows. As a result, the docker logs command can’t see the output from ColdFusion once the container is running.

It turns out there is a very simple and very elegant way to force ColdFusion, or any app which wants to daemonize and write to log files, to write to stdout. From this ServerFault thread referencing the Nginx Dockerfile, you can symlink the coldfusion-out.log file to /dev/stdout:

ln -sf /dev/stdout /opt/coldfusion10/cfusion/logs/coldfusion-out.log

My Dockerfile for ColdFusion has these two lines:

# redirect logs so `docker logs -f <container>` works
RUN ln -sf /dev/stdout /opt/coldfusion10/cfusion/logs/coldfusion-out.log
RUN ln -sf /dev/stderr /opt/coldfusion10/cfusion/logs/coldfusion-err.log

Now the logs can be collected and observed in a centralized location using Docker best practices.

I’ll be speaking at dev.Objective() this year in Minneapolis on a hybrid business/programming topic titled, “Building Multi-Tenant Software-As-A-Service (Saas) Applications” This will be a comprehensive review covering the hurdles I’ve crossed growing MotorsportReg.com from a one-man nights-and-weekends operation to a team that has processed more than $100,000,000 in event entry fees. The talk will cover:

• Database design and tenancy model trade-offs
• Third party services and designing for resiliency
• E-commerce strategies for cards on file, split payments, multiple currencies and marketplace-style apps
• Implications of going global including i18n, l10n, currency and domiciling
• Cross-customer security and the impact of banking and legal requirements such as PCI DSS, IRS and Know-Your-Customer (KYC)
• Code strategies for implementing customer or domain-specific functionality without a “kitchen sink” user experience problem

Developers who are interested in SaaS apps or have the entrepreneurial itch themselves will walk away with a roadmap of the issues a SaaS app must solve and strategies to achieve success. I’ll be speaking immediately after the keynote Wednesday morning, May 13, at 10:15am.

This is my second time attending dev.Objective() and I’m returning because I got a ton of value from it. I hope you’ll consider attending if you’re not already signed up as it will be a positive boost for your creativity and skills. Registration is still available for $999.

Connect with me on twitter ahead of the conference to keep in touch at @ghidinelli. You can connect with other speakers and attendees on Lanyrd

To encourage you to leverage rather than rebuild, I’ve moved the source to GitHub where you can fork and pull:

https://github.com/ghidinelli/cfpayment

There’s also a Google group where I provide support if you want to use a gateway we don’t yet include. I’ll help you understand how to use the library and extend it so you don’t go through the pain of learning the hard way how transactions can fail in production.

ava.lang.StackOverflowError at org.apache.xerces.dom.ParentNode.item(Unknown Source) at
net.sf.saxon.dom.NodeWrapper$ChildEnumeration.skipFollowingTextNodes(NodeWrapper.java:1166) at
net.sf.saxon.dom.NodeWrapper$ChildEnumeration.next(NodeWrapper.java:1194) at
net.sf.saxon.tree.util.Navigator$EmptyTextFilter.next(Navigator.java:918) at
net.sf.saxon.tree.util.Navigator$DescendantEnumeration.advance(Navigator.java:1052) at
net.sf.saxon.tree.util.Navigator$DescendantEnumeration.advance(Navigator.java:1111) at
net.sf.saxon.tree.util.Navigator$BaseEnumeration.next(Navigator.java:949) at
net.sf.saxon.tree.util.Navigator$DescendantEnumeration.advance(Navigator.java:1043) at
net.sf.saxon.tree.util.Navigator$BaseEnumeration.next(Navigator.java:949) at
... (endless repeat)

Something is stuck in a loop but because the stack trace fills up, you can’t see any of the lines of code being executed just before the ka-blammo. So, what to do?

Brute Force Debugging

My solution was to swipe a perl script to run commands at very short intervals and dump jstack output into a series of text files. Low-tech, but effective. This is the timer.pl script:

#!/usr/bin/perl

use strict;
use warnings;
use Time::HiRes qw/time sleep/;

sub launch {
    return if fork;
    exec @_;
    die "Couldn't exec";
}

$SIG{CHLD} = 'IGNORE';

my $interval = shift;
my $start = time();
while (1) {
    launch(@ARGV);
    $start += $interval;
    sleep $start - time();
}

And a separate shell script, dump.sh, so the redirect would create a new file every time it was run. 9892 is just the process id of the ColdFusion instance:

#!/bin/sh
sudo -u nobody /usr/java/latest/bin/jstack 9892 > t_$(date '+%Y%m%d%H%M%S_%N')

I tried running it every second, but that wasn’t enough to catch the stack overflow in the act. I upped it to every 500ms, 100ms and finally 50ms until it caught the offending code. Here’s the command in action:

perl timer.pl 0.05 ./dump.sh 

That says run the dump.sh every 50ms which will output to files formatted like t_20130402171521_009840232 using the current date and time.

Results

Running every 50ms, it doesn’t take long to fill up a directory so I started the script on the command line and in my web browser, triggered the offending code. Here’s what my directory looks like:

 52 t_20130402171519_959011475
 52 t_20130402171520_009648175
 52 t_20130402171520_060316767
 52 t_20130402171520_110450371
 52 t_20130402171520_160301392
 52 t_20130402171520_210357359
 52 t_20130402171520_260432922
 52 t_20130402171520_309171913
 52 t_20130402171520_360033048
 52 t_20130402171520_409978373
 52 t_20130402171520_459903958
 52 t_20130402171520_510488116
 52 t_20130402171520_558777256
 60 t_20130402171520_610244244
 72 t_20130402171520_659494494
136 t_20130402171520_709058569
136 t_20130402171520_760286651
136 t_20130402171520_810351161
136 t_20130402171520_860382457
136 t_20130402171520_910136459
136 t_20130402171520_960370954
136 t_20130402171521_009840232
 72 t_20130402171521_059986004
136 t_20130402171521_110340195
136 t_20130402171521_160277982
136 t_20130402171521_209090149
 84 t_20130402171521_260090368
136 t_20130402171521_310428721
136 t_20130402171521_367027484
136 t_20130402171521_410303418
136 t_20130402171521_460314216
136 t_20130402171521_509053355
136 t_20130402171521_560120477
136 t_20130402171521_610417764
128 t_20130402171521_677647036
136 t_20130402171521_712667159
136 t_20130402171521_758884870
136 t_20130402171521_810562747
136 t_20130402171521_860425517
...

That’s kilobytes in the first column, filename in the second. You can see the steady state while I’m going to push the button in the web browser and then very quickly the stack traces get larger as code is executing. What I wasn’t getting until I stepped down to 50ms iterations were the intermediate 72kb and 84kb stack trace which actually showed the offending lines between the stack overflows churning.

While this hasn’t solved the problem yet, at least I know where to go looking (and it’s at you, XmlSearch()) to continue the troubleshooting process.

Conclusion

This is a pretty hacky solution but if you’re this far into the deep end of the “what do I do?” pool, it’s a useful technique. A line debugger would be far better but I can’t replicate this in my test environment. So, forget the “right” way to do it and let’s just get some useful information so we can make progress.

<cffunction name="setUp" returntype="void" access="public">
	<cfscript>
		variables.beanFactory = createObject("component", "coldspring.beans.DefaultXmlBeanFactory").init();
		variables.beanFactory.loadBeansFromXmlFile("/config/globalbeans.xml", true);
		variables.service = variables.beanFactory.getBean("BatchbookService");
	</cfscript>

	<cfset localMode = true />
</cffunction>

You can read more about my localMode trick for testing remote APIs but I’m simply loading up my Coldspring configuration file for my app which includes dozens and dozens and dozens of beans. I have three problems with this:

1. The unit tests depend on the configuration used to run the site which might not always be in my environment
2. It slows down my tests by generating beans that my unit test doesn’t need
3. My production and test bean config may not be the same (credentials, etc)

I might be able to get around #2 by using lazy init but the principle still holds: the unit test should be as standalone as possible. In the case I’m working on today, I have a client I’ve written (and released) for a third party API from Batchbook. But I need to have some Batchbook-to-My-App conversions of JSON to queries and so forth. I don’t want to bake those into my publicly-released client so what I really want in my production app is some bean config that looks like:

<bean id="BatchbookService" class="model.external.batchbook.BatchbookService">
	<constructor-arg name="BatchbookClient">
		<bean class="model.external.batchbook.batchbook">
	        <constructor-arg name="apikey"><value>password</value></constructor-arg>
	        <constructor-arg name="endpoint"><value>https://somehost.batchbook.com/api/v1</value></constructor-arg>
			<constructor-arg name="restconsumer"><ref bean="restconsumer" /></constructor-arg>
			<constructor-arg name="JSONUtil"><ref bean="JSONUtil" /></constructor-arg>
		</bean>
	</constructor-arg>
</bean>
<bean id="RestConsumer" class="model.external.restconsumer" />
<bean id="JSONUtil" class="model.utils.JSONUtil" />

But if my BatchbookClient is a nested constructor-arg, how can I get it from the beanfactory to test it?

Alternative Coldspring Configurations

Turns out there’s more than one way to load beans into Coldspring and passing a path to an XML configuration file is just one. Looking over the 1.0 reference guide, I found two additional methods of interest:

• loadBeansFromXmlRaw(xmlStringConfig, true)
• loadBeansFromXmlObj(parsedXmlConfig, true)

Applying that to my current unit test, my setup method now looks like:

<cffunction name="setup">
	<cfset var beanConfigs = "" />
	<cfset var localMode = true />

	<cfsavecontent variable="beanConfigs">
		<beans>
			<bean id="BatchbookService" class="model.external.batchbook.BatchbookService">
				<constructor-arg name="BatchbookClient"><ref bean="BatchbookClient" /></constructor-arg>
			</bean>
			<bean id="BatchbookClient" class="model.external.batchbook.batchbook">
		        <constructor-arg name="apikey"><value>password</value></constructor-arg>
		        <constructor-arg name="endpoint"><value>https://somehost.batchbook.com/api/v1</value></constructor-arg>
				<constructor-arg name="restconsumer"><ref bean="restconsumer" /></constructor-arg>
				<constructor-arg name="JSONUtil"><ref bean="JSONUtil" /></constructor-arg>
			</bean>
			<bean id="RestConsumer" class="model.external.restconsumer" />
			<bean id="JSONUtil" class="model.utils.JSONUtil" />
		</beans>
	</cfsavecontent>

	<cfscript>
		variables.beanFactory = createObject("component", "coldspring.beans.DefaultXmlBeanFactory").init();
		variables.beanFactory.loadBeansFromXmlRaw(beanConfigs, true);

		variables.bb = variables.beanFactory.getBean("BatchbookClient");
		variables.svc = variables.beanFactory.getBean("BatchbookService");
	</cfscript>

</cffunction>

Coldspring now instantiates much quicker and it only loads beans related to my unit test. Plus, I have the flexibility to directly address the BatchbookClient and run it through its paces alongside the BatchbookService.

If you only have a few unit tests, these improvements won’t mean much but as your test suites grow (and you work towards continuous deployment…) you will find that speeding up testing is always a good thing and helps encourage you to do it.

The problem is you don’t want to (or can’t…) always send every request over the wire to the remote API. You might develop offline, the remote API might have limits, or real requests may take a long time which is not practical for rapid testing. Sometimes we want to use a mock response and other times we want to connect to the third party to make sure things function properly. How do we write unit tests and integration tests without duplicating our work?

Conditionally Using Mocks

A “mock” is an arbitrarily defined data structure or object that mimics behavior. MxUnit describes mocks providing “the ability to easily and quickly define behaviors for dependencies” which allow us to test more discretely without worrying about dependent data structures, objects or behaviors.

Since the concept of an integration test is different for a headless client library, my approach has been to use MxUnit’s injectMethod() to conditionally override a method for mocking:

<cffunction name="offlineInjector" access="private" hint="conditionally injects a mock if we are running tests in offline mode vs. integration mode">
  <cfif localMode>
    <cfset makePublic(arguments[1], arguments[4]) />
    <cfset injectMethod(argumentCollection = arguments) />
  </cfif>
</cffunction>

localMode is defined in the setup method and is a simple boolean. I replace all usage of injectMethod() to instead use my offlineInjector():

<cfset offlineInjector(clientsvc, this, "anExampleListMock", "myMethodToReplace") />

Each time the test is run, the method will be mocked only if localMode is true. Otherwise, the client library will use connect to the remote API to execute the request. I do most of my development with localMode = true and set it to false when I’m ready to verify everything works both locally and remotely.

There are probably many ways to skin this cat and this has been working well for me without duplicating test code. I used it most recently to wrap up integration with EmailCenterPro and their REST API which lets us use templated emails to send service agreements and welcome new customers as part of our sales process.

CFPAYMENT makes payment processing easy. It’s a ColdFusion library modeled after Ruby’s ActiveMerchant that normalizes various payment gateways to give developers a single interface to process credit card and ACH transactions. After years of production use and tens of millions of dollars processed, I’m proud to announce a 1.0 release is now available at cfpayment.riaforge.org.

There’s a lot of hard work from many different folks that have made this a success. If you’re interested in learning more, download the file and check out docs/cfpayment.pdf or hit up the Google group at http://groups.google.com/group/cfpayment.