Solr
  1. Solr
  2. SOLR-889

Upgrade dependent libraries to most recent stable version

    Details

    • Type: Task Task
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Duplicate
    • Affects Version/s: None
    • Fix Version/s: 3.2
    • Component/s: None
    • Labels:
      None

      Description

      In particular:

      • commons-httpclient-3.1.jar => httpcore-4.0-beta3.jar
      • commons-fileupload-1.2.jar => commons-fileupload-1.2.1.jar
      • commons-io-1.3.1.jar => commons-io-1.4.jar

      perhaps:

      • jetty-6.1.3.jar => jetty-6.1.14.jar

        Activity

        Hide
        Ryan McKinley added a comment -

        Upgrading httpclient / fileupload and commons-io pass all test unchanged.

        Upgrading jetty still has some issues, but I think they may be ok.

        CacheHeaderTest gets an error on testCacheVetoException

        null expected:<[no-cache, ]no-store> but was:<[must-revalidate,no-cache,]no-store>
        
        junit.framework.ComparisonFailure: null expected:<[no-cache, ]no-store> but was:<[must-revalidate,no-cache,]no-store>
        at org.apache.solr.servlet.CacheHeaderTest.checkVetoHeaders(CacheHeaderTest.java:65)
        at org.apache.solr.servlet.CacheHeaderTest.testCacheVetoException(CacheHeaderTest.java:59)
        

        This looks OK to me – the header is contains 'no-cache', but it also contains 'must-revalidate' – I think we can change the test to make it pass...

        Show
        Ryan McKinley added a comment - Upgrading httpclient / fileupload and commons-io pass all test unchanged. Upgrading jetty still has some issues, but I think they may be ok. CacheHeaderTest gets an error on testCacheVetoException null expected:<[no-cache, ]no-store> but was:<[must-revalidate,no-cache,]no-store> junit.framework.ComparisonFailure: null expected:<[no-cache, ]no-store> but was:<[must-revalidate,no-cache,]no-store> at org.apache.solr.servlet.CacheHeaderTest.checkVetoHeaders(CacheHeaderTest.java:65) at org.apache.solr.servlet.CacheHeaderTest.testCacheVetoException(CacheHeaderTest.java:59) This looks OK to me – the header is contains 'no-cache', but it also contains 'must-revalidate' – I think we can change the test to make it pass...
        Hide
        Shalin Shekhar Mangar added a comment -

        I guess commons-fileupload and commons-io has been upgraded. But I see the older version of commons-httpclient and Jetty.

        Should we leave the libs in trunk as-is for 1.4 release?

        Show
        Shalin Shekhar Mangar added a comment - I guess commons-fileupload and commons-io has been upgraded. But I see the older version of commons-httpclient and Jetty. Should we leave the libs in trunk as-is for 1.4 release?
        Hide
        Ryan McKinley added a comment -

        Upgrading httpclient is an API breaking change, so that will have to wait 'till 2.0

        Jetty seems fine, but it requires a change to a test.

        Lets postpone this till after 1.4

        Show
        Ryan McKinley added a comment - Upgrading httpclient is an API breaking change, so that will have to wait 'till 2.0 Jetty seems fine, but it requires a change to a test. Lets postpone this till after 1.4
        Hide
        Jan-Pascal added a comment -

        Hi all,

        I'm running into this issue while packaging Solr 1.3 for Debian. The attached patch fixes the failed test mentioned here, but another test fails later on:

        <testcase classname="org.apache.solr.servlet.CacheHeaderTest" name="testCacheVetoException" time="0.795">
        <failure message="We got no Expires header" type="junit.framework.AssertionFailedError">junit.framework.AssertionFailedError: We got no Expires header
        at org.apache.solr.servlet.CacheHeaderTest.checkVetoHeaders(CacheHeaderTest.java:74)
        at org.apache.solr.servlet.CacheHeaderTest.testCacheVetoException(CacheHeaderTest.java:59)
        </failure>
        </testcase>

        From reading the HTTP 1.1 RFC, the Expires header is essential for the correct operation of HTTP 1.0 caches (that may ignore the "Cache-Control: no-cache" header). That means disabling the test would be incorrect. I haven't been able to find out where the Expires: headers is supposed to be generated.

        Cheers

        Jan-Pascal

        Show
        Jan-Pascal added a comment - Hi all, I'm running into this issue while packaging Solr 1.3 for Debian. The attached patch fixes the failed test mentioned here, but another test fails later on: <testcase classname="org.apache.solr.servlet.CacheHeaderTest" name="testCacheVetoException" time="0.795"> <failure message="We got no Expires header" type="junit.framework.AssertionFailedError">junit.framework.AssertionFailedError: We got no Expires header at org.apache.solr.servlet.CacheHeaderTest.checkVetoHeaders(CacheHeaderTest.java:74) at org.apache.solr.servlet.CacheHeaderTest.testCacheVetoException(CacheHeaderTest.java:59) </failure> </testcase> From reading the HTTP 1.1 RFC, the Expires header is essential for the correct operation of HTTP 1.0 caches (that may ignore the "Cache-Control: no-cache" header). That means disabling the test would be incorrect. I haven't been able to find out where the Expires: headers is supposed to be generated. Cheers Jan-Pascal
        Hide
        Shalin Shekhar Mangar added a comment -

        I haven't been able to find out where the Expires: headers is supposed to be generated.

        It is in HttpCacheHeaderUtil.setCacheControlHeader method

        Show
        Shalin Shekhar Mangar added a comment - I haven't been able to find out where the Expires: headers is supposed to be generated. It is in HttpCacheHeaderUtil.setCacheControlHeader method
        Hide
        Hoss Man added a comment -

        Bulk updating 240 Solr issues to set the Fix Version to "next" per the process outlined in this email...

        http://mail-archives.apache.org/mod_mbox/lucene-dev/201005.mbox/%3Calpine.DEB.1.10.1005251052040.24672@radix.cryptio.net%3E

        Selection criteria was "Unresolved" with a Fix Version of 1.5, 1.6, 3.1, or 4.0. email notifications were suppressed.

        A unique token for finding these 240 issues in the future: hossversioncleanup20100527

        Show
        Hoss Man added a comment - Bulk updating 240 Solr issues to set the Fix Version to "next" per the process outlined in this email... http://mail-archives.apache.org/mod_mbox/lucene-dev/201005.mbox/%3Calpine.DEB.1.10.1005251052040.24672@radix.cryptio.net%3E Selection criteria was "Unresolved" with a Fix Version of 1.5, 1.6, 3.1, or 4.0. email notifications were suppressed. A unique token for finding these 240 issues in the future: hossversioncleanup20100527
        Hide
        Ryan McKinley added a comment -

        this is old, and has been incorporated into other issues

        Show
        Ryan McKinley added a comment - this is old, and has been incorporated into other issues
        Hide
        Robert Muir added a comment -

        Bulk close for 3.2

        Show
        Robert Muir added a comment - Bulk close for 3.2

          People

          • Assignee:
            Ryan McKinley
            Reporter:
            Ryan McKinley
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development