I've been slacking off this 4th of july weekend. I'll try to post something resembing useful comments later in the week. I just skimmed the commits, but so far it seems useful.
peter On Sat, 3 Jul 2004 14:58:19 +0100, Sebastian Bazley <[EMAIL PROTECTED]> wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
