Hello, I have tested your changes from svn. I have these issues: * on HTTP Proxy server, in HTTP Sampler settings section, Type combo list says "HTTP Request" and "HTTP Request HTTPClient". Does have not need to change to Java, HC3.1, HC4? (classes ProxyControlGUI and Proxy)
* On HTTP Request and HTTP Request Defaults, Content encoding's white box disappears when you reduce the JMeter window's width. On my screen (1440x900), when I launch JMeter trunk, with the initial JMeter size, on the HTTP Request sampler, I don't see the white box of Content encoding (label still visible) (I thinks the problem is the FlowLayout in JPanel from UrlConfigGui) Milamber Le 26/11/2010 00:28, sebb a ecrit : > 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 > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
