On Tue, 2011-06-07 at 09:47 +0200, Bart Robeyns wrote: > It is not possible to alter the behaviour of the CachingHttpClient because > the policies defining the behaviour are private and tied directly to > specific implementations in the CachingHttpClients constructor. Furthermore, > these policies are package private, discouraging reuse and/or extensions. > > Making this possible is easy enough (provide some policy-setters or > -constructor-args in CachingHttpClient and make the policy-classes public) - > which leads me to believe that the tight relationships between client and > policies is deliberate. Is this the case, or are you willing to accept a > patch that opens up these classes for extending the caching behaviour? > > The specific case that lead to this question: > > A back-end application only sets its Content-Length header for responses > below 8K. This response does get stored in the cache, but when retrieving it > from the cache, CacheValidityPolicy.contentLengthHeaderMatchesActualLength > checks the Content-Length header with the stored size (to verify whether the > cached content is complete). This check fails, causing the cache entry to be > deemed unusable. If we were able to provide our own subclassed > CacheValidityPolicy, it would be easy to skip the check if the header is > missing and thus accomodate this specific back-end quirk. > > Thanks for any answers, > > Bart
Bart Most of the internal caching logic is package private mainly due to the fact it was deemed too fresh to be made public so we could still tweak it without having to deprecate half of the module. Please re-post your message to the dev list or raise a JIRA with a change request in order to start the discussion about opening up some of the internal caching API. You are also very welcome to submit a patch with the changes you are proposing. This can make the process somewhat easier and quicker. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
