Re: [JMeter] HTTP Sampler consolidation of implementations
On 20 April 2011 22:30, Milamber milam...@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-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
Re: [JMeter] HTTP Sampler consolidation of implementations
On 21 April 2011 01:57, sebb seb...@gmail.com wrote: On 20 April 2011 22:30, Milamber milam...@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. 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: 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
