On 6 December 2010 08:12, Milamber <milam...@apache.org> wrote: > Hello, > >>> 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. >> > > Perhaps [http] is better than ([http]), more readable?
Good point, you're right - and it's shorter. > Milamber > >> >>>> 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 >> >> >> > > > --------------------------------------------------------------------- > 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
