On 2 December 2010 12:59, sebb <seb...@gmail.com> wrote: > 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.
Done. >> * 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. Done. Turned out to be quite easy - just needed to set the minimum size for the panel. > 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. Done. >> 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
