On Apr 11, 2005 2:44 PM, Michael Stover <[EMAIL PROTECTED]> wrote: > I think it would be good to put this stuff in the response object, but > I'm thinking a richer hierarchy might help. For instance, header/body > distinction doesn't make much sense for jdbc results. I think we should > come up with a core of response info, make a base class to reflect that, > and then make children classes to add further details - > > SamplerResult > - getTime, getTimeStamp(),getResponseData(),getRequestData(), etc > HeaderBodyResult > - getHeader(), getBody(), -getResponseData() would return the two > put together > HTTPResult > - This object might know how to extract all the info it needs given > an open HTTPUrlConnection object. (just a thought) > > The listeners would need some adjustment to deal with this. > > So, I'm mostly agreeing with you, just adding to the idea, really. >
OK, I see. [Not sure we can assume an HTTPUrlConnection object, because these are not used by Apache HttpClient.] As far as I can see, at the moment the only classes that use HTTPSampleResult are the HTTP ones - however that may be because SampleResult contains the header fields. The fields that possibly don't belong in SampleResult seem to be: responseHeaders requestHeaders isMonitor (only currently makes sense for HTTP Samples, as far as I can tell) subResults (probably only for HTTP?) HTTPSampleResult has: cookies method queryString redirectLocation all of which seem to be for HTTP only. So it looks like one could move isMonitor and subResults to HTTPSR, and the header fields to a new HeaderSampleResult. == I think getBody() and getHeader() need to be defined for all SampleResults classes, so that users don't have to keep checking. There could be a hasHeader() method for those callers that did need to know. S. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
