On 25 November 2010 23:13, Milamber <milam...@apache.org> wrote: > Hello, > > Your plan seems very well. > > Keep legacy samplers (Java, Hc3) is a good things, but perhaps if there > has three http samplers thus will introduce some confusing for a new > user? (what http sampler is the best for my test?)
It will have to be documented. In theory, HC4 will be the best, but it may take a while to get the JMeter interface code working correctly. So I did not want to replace HC3 with HC4. Once it is well established, HC3 can be made optional, at which point JMeter would revert to two choices again. > (Actually, my understanding is the Java Http sampler is the legacy and > reliable, and Hc3 is new challenger and is better for httpS request...) > > Another ask: what will be the default sampler? Currently it is the Java sampler, but I plan to make it configurable with a JMeter property. > AJP sampler seems not very used like sampler. Keep his independence will > be good for the evolution of federated http sampler. > > Milamber > > Le 25/11/2010 15:45, sebb a ecrit : >> Just a heads up that I'm currently working on trying to combine the >> HTTP implementations (Java, HttpClient3) into a single GUI, with >> run-time choice of implementation. >> >> The rationale for this is that HttpClient 4 is now available, and it >> would be good to add that, but I think we should keep HttpClient for >> backwards compatibility and comparison. >> >> Creating another GUI/Sampler set is easy enough, but it would be >> useful to be able to switch implementations easily - currently that >> requires switching samplers (e.g. by editting the JMX file). >> >> The current plan is to allow the implementation to be specified on the >> HTTP Request Defaults config screen as well as on the HTTP Request >> screen. >> >> The code is a bit involved, because the Config settings are processed >> at run-time after the test plan has been built. >> [But even the Sampler GUI needs to create the sampler before it can >> store the sampler settings - and the implementation can then be >> changed.] >> Currently I use a Sampler Proxy that dispatches to the appropriate >> implementation class. >> These classes have to extend an abstract class that provides the >> necessary methods to interface with the Proxy test element and thus >> provide access to the test element properties. >> That part seems to be working OK. >> >> The next phase is to ensure that existing JMX files can be converted >> (during load) to use the new sampler. >> >> The intention is to keep the existing Java and HttpClient samplers, so >> that subclasses will continue to work, but not expose them in the GUI. >> >> I've not finally decided about the AJP sampler - it can be easily >> converted, but I don't think there's much of a use case for switching >> between AJP and another implementation. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org >> For additional commands, e-mail: dev-h...@jakarta.apache.org >> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org > For additional commands, e-mail: dev-h...@jakarta.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
