Mailing-List: contact dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jakarta.apache.org
Received-SPF: pass (nike.apache.org: domain of sebbaz@gmail.com designates
 209.85.212.44 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type;
        b=rBrfEkfuez0sVi/5eIx0ih1OSNXwmCVaqorwciVV/JVTN6uNh9jLWR1Jvk51PTi0Ar
         zaear26siBWl+nV90XhKyjvJOqGX5Qx2L9VftOzoHpl2R+cLBxkeAKst2/4/R3QKMjwd
         QVZwt5fv0qsO1aOY4ep2c9uJaXJhD9bv4BaJQ=
MIME-Version: 1.0
In-Reply-To: <4DAF5085.9040702@apache.org>
References: <AANLkTin4-tUs_qSHKB5ShSg49of8vhmXEbNZDH7hOPVu@mail.gmail.com>
	<4DAF5085.9040702@apache.org>
Date: Thu, 21 Apr 2011 01:57:13 +0100
Message-ID: <BANLkTim-UWSUoUNPcBR96kR5gr2k7F_P_w@mail.gmail.com>
Subject: Re: [JMeter] HTTP Sampler consolidation of implementations
From: sebb <sebbaz@gmail.com>
To: Milamber <milamber@apache.org>
Cc: dev@jakarta.apache.org
Content-Type: text/plain; charset=ISO-8859-1

On 20 April 2011 22:30, Milamber <milamber@apache.org> 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.

> 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: dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: dev-help@jakarta.apache.org
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: dev-help@jakarta.apache.org