At first glance, I see two ways to accomplish this:
1) The "arms length" approach.
I need to refactor HttpWebResponse and WebResponse to allow subclasses to
supply an input stream and (initial) set of headers. This is on my todo
list to support <meta> tags in servletunit clients. Once this is done, it
will be easy to create a CactusWebResponse to extend WebResponse.
It might then be desirable to let clients define their endXXX method to
take either a WebResponse or an HttpURLConnection. Implementations which
chose the former interface would receive the CactusWebResponse.
2) The "tight integration" approach.
It would be possible along these lines to have Cactus use WebConversation
as its HTTP client. This impacts many more classes, so would be a lot more
work. The potential advantage would be the ability to chain tests, using
the results from one request to create the next request. It is not clear to
me whether this is worth the effort, as Cactus does not seem to preserve
server state between calls, so chaining could be more confusing to users
than helpful.
I could accomplish at least most of (1) fairly soon, I think.
BTW, who is "Heath Robinson"?
