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.

Two huge thumbs up: take a look at this jQuery table grouping demo.

If you’re using TableSorter 2.0.3 or 2.0.5 from 2008, take a look at Rob’s version today.

<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.

Pic linked from wren.

I returned for a second year to co-drive the #3 Tiger Racing BMW M3 in the world’s longest sports car endurance race. For 25 hours, the goal is to keep circulating to amass the most laps.

In reality, what is a season of racing for the machine also tends to bring a season full of drama in one short day. Mechanical failures, collisions with other drivers, sleep deprivation and all-out thrashing by crews to get cars back on track are what make this the ultimate team event.

Drivers have it relatively easy – we can usually sneak a bit of shut-eye or leave the track to get refreshed. The crew usually stays glued to the pit box for 25 hours straight, fingers crossed for nothing other than routine driver swaps, tire changes and refueling but ready for the almost inevitable issues that pop up over 2300 miles of racing.

We had our fair share of issues, starting with an early collision which forced us out of contention but we completed more than half the distance and had a lot of fun doing it. I drove two stints for about 90 laps around the 2.86 mile Thunderhill Raceway and set the fastest time for our team at 3:30am during a night stint.

Both of my stints were in the dark actually and it’s a time that I absolutely love driving. The air is cold and once the tires are hot, it’s a great segment of the race to make up time.

One of the challenges of sharing a car with other drivers is that we aren’t always the same size. This year I had a new seat insert courtesy of Troy Stevens which made a radical difference in my comfort over the course of an hour and forty minutes in the car. I had my SafeRacer gear on from head to toe, including a Stilo ST4F helmet, Alpinestars race suit and gloves and a great Alpinestars Carbon-X base layer that wicked away my sweat so I was both safe and comfortable. I’ve been working hard on my fitness and it paid off.

I look forward to 2013 and returning to put it all together yet again for a run at a podium.

(images couresy of team photographer IngosImages.com)

My favorite question was “What are you most excited about, auto racing, travel or startups?” See what I said.

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.

To help build the biggest, most competitive field possible, I campaigned to change the format to a Double Rational, which is SCCA’s National and Regional racing on track simultaneously. Drivers who primarily race National races would make the tow to earn points and run at Infineon (which hasn’t had a National in well over 5 years) and those who already know how competitive our regional weekends are (40-50 Spec Miatas on average) could come do battle as well. Philosophically and economically, I see no reason to have the distinction between Regional and National racing in the way it’s currently implemented and for this event, I wanted to have huge, competitive fields.

For an inaugural event, I don’t think too many people were disappointed. The Spec Miata group actually sold out more than 10 days in advance of the event when we reached the limit for number of cars permitted on track by the rules. Spec Racer Ford saw huge contingents make the haul from Oregon and Southern California. Our formula car fields looked every bit as full as the Runoffs last year at Road America. The weather was gorgeous, the races were mostly under green flags and the feedback was very positive. It will take a long time before we have the prestige of Chicago Region’s June Sprints (which is now in its 57th year…) but there is no doubt that we had the competitiveness required of a big race.

I had a great weekend, with a lot of old friends making their way back out to the track. TFB Performance finally put humpty dumpty #12 back together again so I could go racing and we had a good haul with one 3rd and two 2nds. Former trailer-sharing-partner Kevin Baillie and I had friends and family out on Sunday for the two races along with my semi-annual Taco Truck catering program and it was another huge success. To end the weekend, I got to stand on the podium with the AIM Tires trophy girls and a big bottle of champagne. Despite not standing on the top step (kudos to Polsley for great drives all weekend long), this was one of the most fun weekends I’ve had and something I hope we can do every summer.

Props to SafeRacer whose Cool Suit system kept me cool as a cucumber during the 40-minute races in the heat. The ability to focus on the race and not think about how hot you are is a huge competitive advantage.