I think pulling in the filter from EHCache is a fine solution. We
could just pull in that single filter's source code (It is ASL 2.0)
rather than add the entire JAR dependency - leaving the dispatch
filter untouched.
Erik
On Nov 16, 2008, at 2:37 AM, Noble Paul (JIRA) wrote:
[ https://issues.apache.org/jira/browse/SOLR-856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12647939
#action_12647939 ]
Noble Paul commented on SOLR-856:
---------------------------------
bq.I don't understand your comment about users having to edit web.xml
OK . I see the argument of keeping it there always.
This means adding a new library dependency . We need to now decide
on which one to choose. Is it mature ? is it buggy?
My immediate concern is SOLR-829 . This issue blocks that. We need
SOLR-829 for our internal purposes (we do replication across
datacenters) and there are other users who need it ASAP.
Any solution is fine
The patch I submitted is the code taken from ehcache. I did not add
extra filter because every request goes through an extra layer .
Do we really need that? Probably we can let the user choose a filter
and document that.
Do we have to add this 60KB jar to our distribution?
Suport for "Accept-Encoding : gzip" in SolrDispatchFilter
---------------------------------------------------------
Key: SOLR-856
URL: https://issues.apache.org/jira/browse/SOLR-856
Project: Solr
Issue Type: Improvement
Reporter: Noble Paul
Attachments: SOLR-856.patch
If the client sends an Accept-Encoding : gzip header then
SolrDispatchFilter should respect that and send back data as zipped
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
