Skip to content
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

Closed
jypma opened this issue Sep 28, 2016 · 1 comment
Closed

Java DSL cannot create ContentTypeResolver #360

jypma opened this issue Sep 28, 2016 · 1 comment
Milestone

Comments

@jypma
Copy link
Member

jypma commented Sep 28, 2016

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 scala ContentTypeResolver, causing JavaMapping to error out with

Illegal custom subclass of akka.http.scaladsl.server.directives.ContentTypeResolver. Please use only the provided factories in akka.http.javadsl.model.Http

I think the simplest solution may be to have a factory around a lambda, rather than an interface, i.e.

def create(java.util.function.Function[String,ContentType]): ContentTypeResolver
@ktoso
Copy link
Member

ktoso commented Sep 28, 2016

Good catch, and the proposed solution is good as well. Should be ContentTypeResolver.create(....)

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.
@jrudolph jrudolph added this to the 10.0.6 milestone Apr 26, 2017
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
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants