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
Java DSL cannot create ContentTypeResolver #360
Milestone
Comments
Good catch, and the proposed solution is good as well. Should be |
jypma
added a commit
to jypma/akka-http
that referenced
this issue
Mar 21, 2017
The JavaMapping class assumes that all Java interfaces have factory methods that only instantiate their Scala subclasses from the scala DSL. That's not the case for ContentTypeResolver, which is only a Java interface and a Scala trait. It's intended to be implemented as a lambda / function. However, when doing that from Java, the Scala trait is not instantiated, upsetting the JavaMapping magic. This commit changes ContentTypeResolver to no longer use the JavaMapping conversion, but rather convert explicitly. By making it a Java 8 functional interface, it can now be directly implemented as a lambda. Binary compatibility is hopefully unaffected, since the default method isn't slapped on until actual Java implementations (which couldn't exist until now).
jrudolph
pushed a commit
that referenced
this issue
Apr 26, 2017
The JavaMapping class assumes that all Java interfaces have factory methods that only instantiate their Scala subclasses from the scala DSL. That's not the case for ContentTypeResolver, which is only a Java interface and a Scala trait. It's intended to be implemented as a lambda / function. However, when doing that from Java, the Scala trait is not instantiated, upsetting the JavaMapping magic. This commit changes ContentTypeResolver to no longer use the JavaMapping conversion, but rather convert explicitly. By making it a Java 8 functional interface, it can now be directly implemented as a lambda. Binary compatibility is hopefully unaffected, since the default method isn't slapped on until actual Java implementations (which couldn't exist until now). Fixes #360.
tomrf1
pushed a commit
to tomrf1/akka-http
that referenced
this issue
Aug 13, 2017
The JavaMapping class assumes that all Java interfaces have factory methods that only instantiate their Scala subclasses from the scala DSL. That's not the case for ContentTypeResolver, which is only a Java interface and a Scala trait. It's intended to be implemented as a lambda / function. However, when doing that from Java, the Scala trait is not instantiated, upsetting the JavaMapping magic. This commit changes ContentTypeResolver to no longer use the JavaMapping conversion, but rather convert explicitly. By making it a Java 8 functional interface, it can now be directly implemented as a lambda. Binary compatibility is hopefully unaffected, since the default method isn't slapped on until actual Java implementations (which couldn't exist until now). Fixes akka#360.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The docs say _Implement this interface to provide a custom mapping _, but implementing just
akka.http.javadsl.server.directives.ContentTypeResolver
makes the target class not be a scalaContentTypeResolver
, causingJavaMapping
to error out withI think the simplest solution may be to have a factory around a lambda, rather than an interface, i.e.
The text was updated successfully, but these errors were encountered: