Closed David-Noble-at-work closed 5 years ago
@David-Noble-at-work the change enables TCP as the default protocol. However there are a lot of test mock which fail due to this change please look at DirectHttpsClientUnderTest
and other places where when instantiating the client it was assumed that it is a direct https and test validates the direct https nature of workflow (http requests etc)
seems there a dependency conflict somewhere
[ERROR] Tests run: 50, Failures: 2, Errors: 0, Skipped: 1, Time elapsed: 104.02 s <<< FAILURE! - in TestSuite
[ERROR] readDocumentThroughTokenResolver(com.microsoft.azure.cosmosdb.rx.examples.TokenResolverTest) Time elapsed: 7.339 s <<< FAILURE!
java.lang.NoSuchMethodError: org.hamcrest.Matcher.describeMismatch(Ljava/lang/Object;Lorg/hamcrest/Description;)V
at com.microsoft.azure.cosmosdb.rx.examples.TokenResolverTest.readDocumentThroughTokenResolver(TokenResolverTest.java:174)
[ERROR] qrderBy_Async(com.microsoft.azure.cosmosdb.rx.examples.DocumentQueryAsyncAPITest) Time elapsed: 4.957 s <<< FAILURE!
java.lang.NoSuchMethodError: org.hamcrest.Matcher.describeMismatch(Ljava/lang/Object;Lorg/hamcrest/Description;)V
at com.microsoft.azure.cosmosdb.rx.examples.DocumentQueryAsyncAPITest.qrderBy_Async(DocumentQueryAsyncAPITest.java:432)
from this build: https://dev.azure.com/azure-cosmos-java/azure-cosmos-java/_build/results?buildId=1429
/azp run
TODO:
[X] Address
DirectHttpsClientUnderTest
issue described by @moderakh below.DirectHttpsClientUnderTest
now ensures that the HTTPS protocol is used.[X] Track down other cases where tests assume the default protocol is HTTPS. Confirmed: no test failures that are the result of assuming the default protocol is HTTPS.
Also found and fixed: A dependency issue introduced by our use of
mockito
andhamcrest
as illustrated here:See the pom.xml changes and run this command to verify the fix.
This issue has also been addressed for v3 on this branch:
danoble/rntbd/v3
anddanoble/rntbd/repeat-v3