[
https://issues.apache.org/jira/browse/SHINDIG-579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Hjelmstad updated SHINDIG-579:
-----------------------------------
Attachment: no-rewrite-in-httpcache.patch
Attaching a fairly sizable patch removing rewriting behavior from
AbstractHttpCache.
Caching is made up by enhancing CachingContentRewriterRegistry, which is
cleaned up to no longer subclass CachingWebRetrievalFactory but instead simply
BasicContentRewriterRegistry (CWRF will soon go the way of the dodo), and now
uses a TtlCache under the hood.
Rewriting of HTTP responses (Gadget already covered in GadgetServer) added to
MakeRequestHandler and ProxyHandler.
Note that this patch means that rewritten HttpResponse objects are no longer
attached to their "parent". Doing so led to confusing code paths and can
essentially only be done effectively in an HttpCache that performs rewriting.
So, cleanup of the HttpResponse object TBD soon.
> Move content rewriting out of AbstractHttpCache and into code best suited to
> utilizing a shared rewritten-content cache
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: SHINDIG-579
> URL: https://issues.apache.org/jira/browse/SHINDIG-579
> Project: Shindig
> Issue Type: Sub-task
> Components: Common Components (Java)
> Reporter: John Hjelmstad
> Attachments: no-rewrite-in-httpcache.patch
>
>
> The fact that rewriting logic for HttpResponses currently lives in
> AbstractHttpCache is confusing, and the implementation of this is even worse.
> All notion of rewriting should be removed from AbstractHttpCache and to
> calling code (eg. MakeRequestHandler) which knows what rewriting semantics
> should apply in context.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
