[
https://issues.apache.org/jira/browse/HTTPCLIENT-972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12893241#action_12893241
]
Oleg Kalnichevski commented on HTTPCLIENT-972:
----------------------------------------------
Jon
HttpParams API often get criticized these days as being cumbersome and user
unfriendly because it is difficult to manipulate with using DI frameworks.
While there is currently no replacement for HttpParams when it comes to
managing HTTP parameters that need to be settable on both per agent and per
request basis, I am certainly guilty for having abused HttpParams in areas
where simple plain java beans would have sufficed (mainly in HttpCore NIO).
Since caching configuration does not seem to make sense at the HTTP request
level, probably we should use plain beans for cache configuration? What do you
think?
Oleg
> caching module should use HttpParams-style configuration
> --------------------------------------------------------
>
> Key: HTTPCLIENT-972
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-972
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: Cache
> Affects Versions: 4.1 Alpha2
> Reporter: Jonathan Moore
> Priority: Minor
> Attachments: cache-params.patch
>
>
> The constructor for CachingHttpClient currently accepts combinations of:
> * HttpCache
> * HttpClient
> * integer for max object size in bytes
> As I started looking at being able to configure this for behaving as a
> non-shared cache, I realized that we actually want to be replacing that last
> int with an HttpParams argument, and tracking all the various options in that
> style. I have a patch with this update which I will upload shortly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
