I was trying to figure out a networking issue (turns out that it's related to the access rights in the training room) when I stumbled across a nasty little bug in BottomFeeder. In Bf, I use a HTTP package called NetResources, which adds application level niceties on top of the stock HTTP libs in VisualWorks - cookie management, caching, and a number of other things. As part of that, we add extensions to the HttpClient class, and also override the class definition. That's where things got hairy.

If you override class definitions, you really need to check them with each new release of the base product. I didn't do that, and I ran into this - here's the stock definition of the class:

Smalltalk.Net defineClass: #HttpClient
	superclass: #{Net.NetClient}
	indexedType: #none
	private: false
	instanceVariableNames: 'request proxyHost keepAlive useProxy connection
 entityParsingOptions cookieAgent enableCookies protocol authPolicy '
	classInstanceVariableNames: ''
	imports: ''
	category: 'Net-HTTP-Support'

And here's what I had in 7.3:

Smalltalk.Net defineClass: #HttpClient
	superclass: #{Net.NetClient}
	indexedType: #none
	private: false
	instanceVariableNames: 'request proxyHost keepAlive useProxyAuthorization connection
 entityParsingOptions cookieAgent enableCookies protocol originalResponse '
	classInstanceVariableNames: ''
	imports: ''
	category: 'Net-HTTP-Support'

The variable "originalResponse" was added so that after certain exceptions, we could go back and examine the state. The big problem is that other than that, the definitions should match (and they didn't). I patched that this morning, but I think I'll do a fresh build when I get back from this trip. Grab the patch for Http-Overrides in the meantime!

Technorati Tags: development, BottomFeeder