-
Notifications
You must be signed in to change notification settings - Fork 595
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Preserve http2 option when going from javadsl to scaladsl #2149
Conversation
Test FAILed. |
0c6a4ec
to
7c23395
Compare
Test PASSed. |
I think this refs #2110 ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pretty tricky to understand this structure, digging into it a bit more
@@ -167,6 +168,9 @@ final class ConnectHttpImpl(val host: String, val port: Int, val http2: UseHttp2 | |||
def isHttps: Boolean = false | |||
|
|||
def connectionContext: Optional[HttpsConnectionContext] = Optional.empty() | |||
|
|||
override def effectiveConnectionContext(fallbackContext: ConnectionContext): ConnectionContext = | |||
HttpConnectionContext(http2.asScala) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So this always ignores the host
, port
, connectionContext
and the fallbackContext
parameter? That seems odd..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah connectionContext
is the HTTPS context so that might make sense to ignore here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This did take me a couple of hours 😕
I find the API very confusing bewtween the ConnectHttp and Context.
the connectionContext
is only Https so a user can't ever have called withContext
and set a custom one here.
I think that is a restriction in the API that we could remove but it wouldn't be binary/source compatible so this was a quick way to make it work without breaking any existing users.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The host and port are ignored here but when the delegation to the scaladsl from the javadsl they are taken from the ConnectHttp and passed in
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah seems to make sense, just trying to digest the change ;)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, so if I'm reading this right, what makes this confusing is that the http2
field is present both on the ConnectHttp
and on the ConnectionContext
. This is different from the host
and port
fields, which are only on the ConnectHttp
. For HTTP, ConnectionContext
actually doesn't contain much interesting information, while for HTTPS it does have some settings.
I agree for HTTP, just creating a HttpConnectionContext
with the http2
setting seems fine: the ConnectionContext
doesn't contain other interesting configuration so ignoring the 'fallback' is harmless.
For HTTPS it's a bit more complicated, but seems OK as well since if you're overriding HttpsConnectionContext
you should be knowing what you're doing anyway.
Would appreciate a second review though :).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem I see with this solution is that 1. it might break down if we add other fields to HttpConnectionContext
in the future and 2. that the flag seems still to be lost for the HTTPS case.
I tried a slightly different approach here: chbatey#1
if (connectionContext.isPresent) connectionContext.get() | ||
else fallbackContext | ||
connectionContext | ||
.map[ConnectionContext](c ⇒ c: ConnectionContext) // covariance, anyone? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed :(
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, seems sensible!
Test FAILed. |
PLS BUILD |
Test FAILed. |
4f5d006
to
f1f47f4
Compare
Compilation failed with a Scala 2.11 type inference problem... Hopefully fixed now :) |
Test PASSed. |
Hey, scalac 2.11, you are a pain (though, I know having to deal with Java existentials is not your fault). Great, however, that these bugs have been fixed in 2.12! |
f1f47f4
to
69df59e
Compare
The only information passed from javadsl to the scaladsl in Http was the context which for Http connections was always the default one meaning that setting http2 always had no effect.
69df59e
to
afe0f24
Compare
Test FAILed. |
Test PASSed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks for finishing this!
The only information passed from javadsl to the scaladsl in Http
was the context which for Http connections was always the default one
meaning that setting http2 always had no effect.
This seed the easiest way not to break the user facing API