-
Notifications
You must be signed in to change notification settings - Fork 594
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
http: deprecate more of coding infrastructure #3294
http: deprecate more of coding infrastructure #3294
Conversation
269cf49
to
90dd6a4
Compare
…zip etc Refs akka#2916 Previously, we exposed Scala objects as API directly which exposes implementation details and makes it hard to evolve the implementation. Instances in coders are upcasted to `Coder` so that implementation details are not leaked any more.
90dd6a4
to
2718dee
Compare
Test FAILed. !!! Couldn't read commit file !!! |
Test FAILed. !!! Couldn't read commit file !!! |
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.
The doc examples show |
Test FAILed. Pull request validation reportFailed Test SuitesTest result for 'akka-http-tests / Pr-validation / ./ executeTests'
Test result for 'docs / Pr-validation / ./ executeTests'
|
import scala.collection.immutable | ||
|
||
@silent("in package coding is deprecated") | ||
object Coders { |
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 structure follows the javadsl more closely. However, on the java side, they part of enum Coder
(singular term). Should we move those into the Coder
companion object as well? In other parts of the (model) API, we tried to put those instances into a plural-named object, so that's why I went with that.
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.
Good to be consistent with e.g. StatusCodes
I think, indeed
def encode(input: ByteString): ByteString = newCompressor.compressAndFinish(input) | ||
|
||
def encodeAsync(input: ByteString)(implicit mat: Materializer): Future[ByteString] = |
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.
Unfortunately, the non-async version is already taken, so it's slightly inconsistent between decoding and encoding side.
Thanks, I tried to go through the warnings, but it seems adding a deprecation didn't recompile dependencies so I missed all of those. |
Test FAILed. Pull request validation reportFailed Test SuitesTest result for 'akka-http-tests / Pr-validation / ./ executeTests'
Test result for 'docs / Pr-validation / ./ executeTests'
|
It seems `encodeAsync` which is now used for comparison is slightly less efficient than the previous sync version
def Gzip: Coder = akka.http.scaladsl.coding.Gzip | ||
def Gzip(messageFilter: HttpMessage => Boolean): Coder = new Gzip(messageFilter) | ||
|
||
def Deflate: Coder = akka.http.scaladsl.coding.Gzip |
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.
oops
Test FAILed. !!! Couldn't read commit file !!! |
Test PASSed. |
import scala.collection.immutable | ||
|
||
@silent("in package coding is deprecated") | ||
object Coders { |
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.
Good to be consistent with e.g. StatusCodes
I think, indeed
import akka.http.scaladsl.model._ | ||
import akka.http.scaladsl.model.headers.HttpEncodings | ||
|
||
class Gzip private (compressionLevel: Int, val messageFilter: HttpMessage => Boolean) extends Coder with StreamDecoder { | ||
@InternalApi | ||
@deprecated("Actual implementation of Gzip is internal, use Coders.Gzip instead", since = "10.2.0") |
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.
It's a bit strange to mark internal API as deprecated, but indeed as it used to be public API I guess it makes sense 👍
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, guess I went over the top with deprecating stuff, just to be sure. Maybe we can create an internal copy later as the future version while keeping that one around only for compatibility.
I did another round on this to use the non-deprecated variants in the tests. |
Test PASSed. |
Thanks, much appreciated :) I'm planning to do a more thorough review of warnings and documentation for 10.2.0 next week. |
Refs #2916
Previously, we exposed Scala objects as API directly which exposes implementation
details and makes it hard to evolve the implementation. Instances in coders
are upcasted to
Coder
so that implementation details are not leaked any more.