As can be seen from the recent commits, I've been looking at the HTTP package structure in some detail just lately when fixing bug 29884.
There are still quite a few classes that assume that there is only one HTTP Sampler (i.e. using the standard Java classes). I'd like to generalize this, to make it easier for users to choose which implementation they want to use. The proposed changes fall under several areas. HTTP GUI ======== It seems to me that it would be useful to combine the GUIs, and add a means to select the implementation on the default page or the sampler itself, probably as a drop-down list showing the handler types. I propose to do this by extending the original GUI class, and removing the new one. This will mean that saved test plans using the new GUI would no longer work, but I think that can be overcome by using the upgrade.properties file to change the class name, and including some special handling to change the value of the HTTP handler field accordingly. I also propose to add a property to select the default handler, so that users could use existing original test plans and have them automatically use a new handler. This would only apply if the test plan did not specify the value. [I suppose there could also be a handler override property.] Static Factory ========== It would probably be useful to have a static factory to create an instance of the appropriate handler. This would contain various methods for chosing the appropriate sampler, e.g. by name, by class, by instance. It can also have a default handler that is decided at run-time. [Could be part of HTTPSamplerBase, I suppose.] Samplers that extend or use HTTPSampler ============================= These are AccessLog, Soap, and WebService. It seems to me that rather than extending HTTPSampler, these could create an instance of the an HTTP sampler and use that. This would allow the existing HTTPSamplers to be made final. Then it would be possible to change which handler to use. [I've not looked into how one sh ould present the option to the user.] The class StandardGenerator currently creates an instance of HTTPSampler; this could/should also be made changeable. The Proxy classes currently assume that it generates only HTTPSampler classes; this could be made variable fairly easily. The trickier bit ========== At least it seems to be the trickiest part: The HtmlParsingUtils.createUrlFromAnchor() method needs to create an HTTP Sampler; this is currently the original sampler. As far as I can see, this needs to create a sampler of the same type as the one the caller is using, but there does not seem to be any way to obtain this information currently, and there is no guarantee that the same handler will be used throughout a test. It would be possible to pass in the original instance of the class (or at least the class name), but the hierarchy is quite complicated (it includes a recursive call), so before proceeding further, it would be useful to know if I'm correct in thinking that it needs to choose the correct sampler? What do you all think? It's not necessary to do any of it; and some parts can be done in isolation. I've not *tried* any of it yet, so I may have overlooked something obvious... Sebastian --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
