You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jakarta.apache.org by Milamber <mi...@apache.org> on 2011/04/04 00:19:08 UTC
Re: [JMeter] HTTP Sampler consolidation of implementations
Hello,
Currently I works to add a optional property to get response size (in
bytes) by different methods:
1/ default (responses data size (uncompressed length if gzip)
2/ responses headers length + default (response data size)
2/ responses headers length + content-length value (real size if gzip)
See:
https://issues.apache.org/bugzilla/show_bug.cgi?id=43363
https://issues.apache.org/bugzilla/show_bug.cgi?id=50170
When I testing my future patch, I found this bug on HC4 Impl:
When Web server (Apache 2.2) uses mod_deflate to compress response data,
the data remains compress data (in view results tree, we have the
compress characters and getBytes() is the compressed length)
I thinks that must add a code section in sample() method when JMeter
reads response data, to decode GZip response if needs, like HC3Impl?
(perhaps HC4 has a specific method to do this?)
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
Re: [JMeter] HTTP Sampler consolidation of implementations
Posted by sebb <se...@gmail.com>.
On 6 April 2011 23:11, Milamber <mi...@apache.org> wrote:
>
>>> When Web server (Apache 2.2) uses mod_deflate to compress response data,
>>> the data remains compress data (in view results tree, we have the
>>> compress characters and getBytes() is the compressed length)
>>>
>>> I thinks that must add a code section in sample() method when JMeter
>>> reads response data, to decode GZip response if needs, like HC3Impl?
>>> (perhaps HC4 has a specific method to do this?)
>>>
>> HC4 should do this automatically, I think, but there was a bug whereby
>> 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?
>>
>
> I uses last JMeter with HC v4.1.1
> httpclient-4.1.1.jar
> httpmime-4.1.1.jar
> and
> httpcore-4.1.jar
>
> Response headers (extract) :
> Server: Apache/2.2.16 (Unix) DAV/2
> Accept-Ranges: bytes
> Vary: Accept-Encoding
> Content-Encoding: gzip
> Content-Length: 70
>
> Request Headers:
> Connection: keep-alive
> Accept-Encoding: gzip,deflate
>
> (I've tested on Linux/JDK 5 / 6 and WinXP JDK6: same issue)
>
> Issue too with www.google.com
Thanks, that was useful, though strangely google would not gzip until
I added a User-Agent of Firefox. Accepting gzip was not enough.
Code now fixed - HC4 does support gzip decoding, but not by default.
> Milamber
>>
>>> 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
Re: [JMeter] HTTP Sampler consolidation of implementations
Posted by Milamber <mi...@apache.org>.
>> When Web server (Apache 2.2) uses mod_deflate to compress response data,
>> the data remains compress data (in view results tree, we have the
>> compress characters and getBytes() is the compressed length)
>>
>> I thinks that must add a code section in sample() method when JMeter
>> reads response data, to decode GZip response if needs, like HC3Impl?
>> (perhaps HC4 has a specific method to do this?)
>>
> HC4 should do this automatically, I think, but there was a bug whereby
> 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?
>
I uses last JMeter with HC v4.1.1
httpclient-4.1.1.jar
httpmime-4.1.1.jar
and
httpcore-4.1.jar
Response headers (extract) :
Server: Apache/2.2.16 (Unix) DAV/2
Accept-Ranges: bytes
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 70
Request Headers:
Connection: keep-alive
Accept-Encoding: gzip,deflate
(I've tested on Linux/JDK 5 / 6 and WinXP JDK6: same issue)
Issue too with www.google.com
Milamber
>
>> 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
Re: [JMeter] HTTP Sampler consolidation of implementations
Posted by sebb <se...@gmail.com>.
On 7 April 2011 00:07, sebb <se...@gmail.com> wrote:
> On 6 April 2011 23:36, Milamber <mi...@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
Re: [JMeter] HTTP Sampler consolidation of implementations
Posted by sebb <se...@gmail.com>.
On 6 April 2011 23:36, Milamber <mi...@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.
> 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
Re: [JMeter] HTTP Sampler consolidation of implementations
Posted by Milamber <mi...@apache.org>.
> 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?
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
Re: [JMeter] HTTP Sampler consolidation of implementations
Posted by sebb <se...@gmail.com>.
On 3 April 2011 23:19, Milamber <mi...@apache.org> wrote:
> Hello,
>
> Currently I works to add a optional property to get response size (in
> bytes) by different methods:
> 1/ default (responses data size (uncompressed length if gzip)
> 2/ responses headers length + default (response data size)
> 2/ responses headers length + content-length value (real size if gzip)
> See:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=43363
> https://issues.apache.org/bugzilla/show_bug.cgi?id=50170
>
> When I testing my future patch, I found this bug on HC4 Impl:
>
> When Web server (Apache 2.2) uses mod_deflate to compress response data,
> the data remains compress data (in view results tree, we have the
> compress characters and getBytes() is the compressed length)
>
> I thinks that must add a code section in sample() method when JMeter
> reads response data, to decode GZip response if needs, like HC3Impl?
> (perhaps HC4 has a specific method to do this?)
HC4 should do this automatically, I think, but there was a bug whereby
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