One of the important proposed changes to JMeter was to switch from the java.net HTTP client to the Apache Jakarta Commons HTTPClient.
I've been reading through HttpClient's docs, and the changes are not trivial.
To start with, the equivalents of our cookie manager and authentication manager (including proxy authentication) are part of one single object, the HttpState. I'm not so sure we can keep their functionality separate and still have reasonably clean and efficient code.
Next, there's really no control over usage of keep-alive, as far as I can see: it will always try to use it. I'm not sure this is really a problem, since it matches the behaviour of most clients. And you can choose which protocol level to use: HTTP 1.0 or 1.1, which is obviously an advantage.
There's other small quirks. For example: I don't see support for our "Includes Equals" features of HTTP Request Parameters. This means we would not be able to shift responsibility for the generation of the query string to the HttpClient. Unless, of course, we can influence the Commons team to add that functionality for us. [Q: do we really need to control that per-parameter? Wouldn't a global setting be enough? Mike: you implemented this -- can you remember the rationale behind the requirement?]
The following funcionalities are poorly implemented in JMeter and would most likely benefit from moving to HttpClient:
- Multipart POST requests
- Cookie handling.
- Authentication (support for non-Basic auth, for example).
- Connection pooling in keep-alive mode.
- Unit testing: HttpClient comes with a test webapp, that we could use to write equivalent JMeter tests.
IMO, the last two above are enough to justify the change to HttpClient.
The following functionalities (of those where I expected HttpClient to help) will not improve at all, and we will still need to handle them ourselves:
- Request parameter encoding
- Follow redirects
- byte[]-to-String translation of responses
- Cache management (not yet there in JMeter)
My proposal is to start by creating completely new components ("New HTTP Sampler", e.g.). When we will be sure they work well, we will deprecate the old components, possibly removing them from the menus. Eventually we should be able to remove them from the codebase (maybe in a 2.0 release...). If we're careful enough, we could even manage to get most config elements and pre-processors to work for both...
Opinions?
-- Salut,
Jordi.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
