Re: [JMeter] HTTP Sampler consolidation of implementations

On 21 April 2011 01:57, sebb <[email protected]> wrote:
> On 20 April 2011 22:30, Milamber <[email protected]> wrote:
>> Hello,
>>
>> HTTPClient 3.1 sampler always have a (hidden) Cookie Manager (the defaut
>> policy: ignore cookie seems don't works)
>
> Looks like this is a new bug - the example works correctly in JMeter 2.4.
>
> I must have messed something up when converting the HC3.1 sampler to
> the new class layout.
>
> I'll take a look shortly.

Fixed.

>
>> With JMeter trunk and HC3.1 sampler, if you test a website with a login page
>> which used a auth session ID cookie to keep track user session and *without*
>> a JMeter cookie manager, the connection works and we can accessed on
>> protected resources.
>> The normal case is: if no cookie manager, we don't have a access on
>> protected resources (we have a error 408 with tomcat examples)
>>
>>
>> (an example Webapp is provided with tomcat archive :
>> http://localhost:8080/examples/jsp/security/protected/
>> don't forget to uncommented users/roles in tomcat_home/conf/tomcat-users.xml
>> before running tomcat)
>>
>> Simple test case.
>
> Thanks - well spotted!
>
>> Milamber
>>
>> Le 25/11/2010 16: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: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>>
>>
>