You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by sebb <se...@gmail.com> on 2010/12/13 12:20:46 UTC
Allow access to default HttpParams
For HC 3.1, JMeter supports a configuration file which can be used to
set up global defaults.
There is no concept of global defaults in HC 4.x, but one can
initialise HttpClient with a DefaultedHttpParams to get similar
functionality.
The method DefaultHttpClient.createHttpParams() creates a default set
of parameters (HttpVersion etc.), however it is not static (so it
means creating a temporary HttpClient) and it forces one to use
SyncBasicHttpParams.
This makes it harder than it could be to create the initial parameter set.
I think it would be useful to expose the defaults as a static method,
with parameter HttpParams, and call that from createHttpParams().
Any objections to adding that?
Or is there a better way of achieving the same goal?
Perhaps the defaults belong in AbstractHttpClient?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Allow access to default HttpParams
Posted by sebb <se...@gmail.com>.
On 14 December 2010 13:27, Oleg Kalnichevski <ol...@apache.org> wrote:
>> >
>> > Makes sense to me.
>>
>> How about adding entrySet() to the HttpParams interface?
>
> We can't do that
>
>> Without that, DefaultedHttpParams has to assume that its local
>> HttpParams extends AbstractHttpParams.
>>
>> Changing the interface would of course break any code that implements
>> the HttpParams interface without extending AbstractHttpParams.
>>
>> I suppose one could extend the HttpParams interface to add the
>> entrySet, and have AbstractHttpParams implement that instead.
>>
>
> An extended or an optional interface should be ok, though
>
> How about an optional interface or something similar?
>
> interface HttpParamSet {
>
> Iterator iterator();
>
> }
Just realised that won't gain anything, because the classes such as
DefaultedHttpParams have to support HttpParams.
I think the best one can do is to add the method to the abstract
parent class (which most - if not all - implementations will use
anyway).
The optional interface could be added later if independent
implementations of HttpParams needed to support entrySet - but I'm not
sure it's worth adding it now?
> Oleg
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Allow access to default HttpParams
Posted by Oleg Kalnichevski <ol...@apache.org>.
> >
> > Makes sense to me.
>
> How about adding entrySet() to the HttpParams interface?
We can't do that
> Without that, DefaultedHttpParams has to assume that its local
> HttpParams extends AbstractHttpParams.
>
> Changing the interface would of course break any code that implements
> the HttpParams interface without extending AbstractHttpParams.
>
> I suppose one could extend the HttpParams interface to add the
> entrySet, and have AbstractHttpParams implement that instead.
>
An extended or an optional interface should be ok, though
How about an optional interface or something similar?
interface HttpParamSet {
Iterator iterator();
}
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Allow access to default HttpParams
Posted by sebb <se...@gmail.com>.
On 14 December 2010 09:03, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Tue, 2010-12-14 at 01:41 +0000, sebb wrote:
>> On 13 December 2010 20:32, Oleg Kalnichevski <ol...@apache.org> wrote:
>> > On Mon, 2010-12-13 at 16:35 +0000, sebb wrote:
>
> ...
>
>> > Feel free to introduce an iterator to BasicHttpParams / SyncHttpParams
>> > classes.
>>
>> I added entrySet() to BasicHttpParams, and added a basic test.
>>
>> However, I now wonder whether it should be also added to the abstract
>> super-class and/or DefaultedHttpParams?
>>
>
> Makes sense to me.
How about adding entrySet() to the HttpParams interface?
Without that, DefaultedHttpParams has to assume that its local
HttpParams extends AbstractHttpParams.
Changing the interface would of course break any code that implements
the HttpParams interface without extending AbstractHttpParams.
I suppose one could extend the HttpParams interface to add the
entrySet, and have AbstractHttpParams implement that instead.
Otherwise, DefaultedHttpParams.entrySet() could just generate an
Exception if the set cannot be generated.
> Oleg
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Allow access to default HttpParams
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Tue, 2010-12-14 at 01:41 +0000, sebb wrote:
> On 13 December 2010 20:32, Oleg Kalnichevski <ol...@apache.org> wrote:
> > On Mon, 2010-12-13 at 16:35 +0000, sebb wrote:
...
> > Feel free to introduce an iterator to BasicHttpParams / SyncHttpParams
> > classes.
>
> I added entrySet() to BasicHttpParams, and added a basic test.
>
> However, I now wonder whether it should be also added to the abstract
> super-class and/or DefaultedHttpParams?
>
Makes sense to me.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Allow access to default HttpParams
Posted by sebb <se...@gmail.com>.
On 13 December 2010 20:32, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Mon, 2010-12-13 at 16:35 +0000, sebb wrote:
>
>> ==
>>
>> I think there should be a public method which gives access to a
>> read-only copy of the parameters.
>> This could either be done by:
>> * changing BasicHttpParams#copyParams(HttpParams target) to be public,
>> in which case we probably need to add a synch. version to the
>> subclass.
>> * or, provide public access to a read-only iterator (again, might need
>> to have synch. version for the subclass).
>>
>> Note: I have got a work-round for JMeter, but it is a bit messy.
>>
>> It seems to me that other application code may have similar use cases
>> - it would certainly be useful to be able to enumerate HttpParams for
>> debugging purposes.
>>
>
> Feel free to introduce an iterator to BasicHttpParams / SyncHttpParams
> classes.
I added entrySet() to BasicHttpParams, and added a basic test.
However, I now wonder whether it should be also added to the abstract
super-class and/or DefaultedHttpParams?
> You do not need to do anything special for the synchronized
> versions as usually iterators are not thread-safe. It is a common
> practice that one must explicitly synchronize of the instance prior to
> using it.
OK
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Allow access to default HttpParams
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Mon, 2010-12-13 at 16:35 +0000, sebb wrote:
> ==
>
> I think there should be a public method which gives access to a
> read-only copy of the parameters.
> This could either be done by:
> * changing BasicHttpParams#copyParams(HttpParams target) to be public,
> in which case we probably need to add a synch. version to the
> subclass.
> * or, provide public access to a read-only iterator (again, might need
> to have synch. version for the subclass).
>
> Note: I have got a work-round for JMeter, but it is a bit messy.
>
> It seems to me that other application code may have similar use cases
> - it would certainly be useful to be able to enumerate HttpParams for
> debugging purposes.
>
Feel free to introduce an iterator to BasicHttpParams / SyncHttpParams
classes. You do not need to do anything special for the synchronized
versions as usually iterators are not thread-safe. It is a common
practice that one must explicitly synchronize of the instance prior to
using it.
Cheers
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Allow access to default HttpParams
Posted by sebb <se...@gmail.com>.
On 13 December 2010 15:08, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Mon, 2010-12-13 at 11:20 +0000, sebb wrote:
>> For HC 3.1, JMeter supports a configuration file which can be used to
>> set up global defaults.
>>
>> There is no concept of global defaults in HC 4.x, but one can
>> initialise HttpClient with a DefaultedHttpParams to get similar
>> functionality.
>>
>> The method DefaultHttpClient.createHttpParams() creates a default set
>> of parameters (HttpVersion etc.), however it is not static (so it
>> means creating a temporary HttpClient) and it forces one to use
>> SyncBasicHttpParams.
>>
>> This makes it harder than it could be to create the initial parameter set.
>>
>> I think it would be useful to expose the defaults as a static method,
>> with parameter HttpParams, and call that from createHttpParams().
>>
>> Any objections to adding that?
>
> I guess not.
OK, I propose to create:
public static void setDefaultHttpParams(HttpParams)
>> Or is there a better way of achieving the same goal?
>> Perhaps the defaults belong in AbstractHttpClient?
>>
>
> Overriding AbstractHttpClient#determineParams() method and returning a
> stack consisting of request, client and global parameters would probably
> be the least intrusive.
Unfortunately that's not entirely suitable for JMeter, which needs to
be able to override the httpclient defaults.
And the approach would still use SyncBasicHttpParams for the defaults.
It's not easy to copy the parameters from SyncBasicHttpParams into
BasicHttpParams, as there is no iterator, and the copy(params) method
is protected.
Further, all the work re-arranging the parameter stack would have to
be done for each request, instead of once per httpclient creation.
==
I think there should be a public method which gives access to a
read-only copy of the parameters.
This could either be done by:
* changing BasicHttpParams#copyParams(HttpParams target) to be public,
in which case we probably need to add a synch. version to the
subclass.
* or, provide public access to a read-only iterator (again, might need
to have synch. version for the subclass).
Note: I have got a work-round for JMeter, but it is a bit messy.
It seems to me that other application code may have similar use cases
- it would certainly be useful to be able to enumerate HttpParams for
debugging purposes.
> Oleg
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
Re: Allow access to default HttpParams
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Mon, 2010-12-13 at 11:20 +0000, sebb wrote:
> For HC 3.1, JMeter supports a configuration file which can be used to
> set up global defaults.
>
> There is no concept of global defaults in HC 4.x, but one can
> initialise HttpClient with a DefaultedHttpParams to get similar
> functionality.
>
> The method DefaultHttpClient.createHttpParams() creates a default set
> of parameters (HttpVersion etc.), however it is not static (so it
> means creating a temporary HttpClient) and it forces one to use
> SyncBasicHttpParams.
>
> This makes it harder than it could be to create the initial parameter set.
>
> I think it would be useful to expose the defaults as a static method,
> with parameter HttpParams, and call that from createHttpParams().
>
> Any objections to adding that?
I guess not.
> Or is there a better way of achieving the same goal?
> Perhaps the defaults belong in AbstractHttpClient?
>
Overriding AbstractHttpClient#determineParams() method and returning a
stack consisting of request, client and global parameters would probably
be the least intrusive.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org