On 2 December 2010 07:34, Milamber <milam...@apache.org> wrote: > 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)
Good point; I'll fix that. > * 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) Yes, I need to fix that too. Previously, the "Web Server" section immediately above stopped this happening, because it has a minimum size that is slightly larger than was needed for the Protocol/Method/Encoding The screen is already quite tall, so I did not want to add another line to it. I can maybe shorten some of the labels as well - e.g. change "Protocol (default http)" to "Protocol ([http])" - this should still be clear enough. > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
