jakarta-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [JMeter] HTTP Sampler consolidation of implementations
Date Thu, 07 Apr 2011 00:50:54 GMT
On 7 April 2011 00:07, sebb <sebbaz@gmail.com> wrote:
> On 6 April 2011 23:36, Milamber <milamber@apache.org> wrote:
>>
>>> HC4 should do this automatically, I think, but there was a bug whereby
>>>
>>
>> I have found this problem too:
>> Unlike HC3, HC4 sampler works with a HTTPS website with a trusted
>> certificate (verisign, thawte, etc.) but doesn't works with self-signed
>> ssl certificate.
>> I've found a TODO in HTTPHC4Impl (line 439), thus I suppose that is normal?
>
> No, I forgot.
> That needs to be fixed so that all certificates are accepted, same as for HC3.
> I'll fix that shortly.

Fixed.

>> Milamber
>>
>>
>>> it did not recognise some encoding methods:
>>>
>>> https://issues.apache.org/jira/browse/HTTPCLIENT-1063
>>>
>>> As far as I can tell, the x-gzip fix is in httpclient 4.1.1 (which
>>> JMeter trunk was recently updated to use).
>>>
>>> Can you check which version of HC4 you were using, and the
>>> Content-type used by Apache 2.2?
>>>
>>>
>>>> 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-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
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>

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


Mime
View raw message