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

Play server interpreter impl #291

Merged
merged 31 commits into from Apr 1, 2020
Merged

Conversation

ghostbuster91
Copy link
Contributor

@ghostbuster91 ghostbuster91 commented Nov 5, 2019

Issues that need to be resolved:

This closes #65

override def headers: Seq[(String, String)] = request.headers.headers
override def queryParameter(name: String): Seq[String] = request.queryString.get(name).toSeq.flatten
override def queryParameters: Map[String, Seq[String]] = request.queryString
override def bodyStream: Any = ???
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How to get a body stream here? I found that there is even an Accumulator.source but every accumulator evaluates to a Future. How to just get a Source[Byte, _]?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pretty sure that Play framework does not support input body streaming. How should we handle this case, what do we want to return here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for a clarification. As discussed with @adamw we will throw an exception here.

Multipart.handleFilePartAsTemporaryFile(serverOptions.temporaryFileCreator)
)
bodyParser.apply(request).run().flatMap {
case Left(value) => Future.failed(new RuntimeException(s"TODO handle it $value")) // what to do here?
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why this happens while handling multipart/form-data? Should we use some other BodyParser?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@zZKato any idea how to fix this? From my investigation it seems that play does some magic behind the scenes, before throwing it into multipartFormData body parser.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ghostbuster91 I think the problem here is that you handle the whole request as a FilePart even though we also have to consider DataParts (afaik).

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll investigate a bit further

@vigimite
Copy link

vigimite commented Nov 18, 2019

I have implemented the Tapir output to Play response part for MultipartFormData, can i have write permissions on this branch? (It is a bit of a hacky implementation but it is the same as PlayServer does it with its BodyWriteable for MultipartFormData)

@ghostbuster91
Copy link
Contributor Author

I am not sure how to give you permission to only this branch, I don't think that there is such an option. AFAIK you can update your fork, so you will have this branch. And then open a new pull request. That way both of us will have a write permissions.

@vigimite
Copy link

I created a PR that merges the commits into this branch from the forked repo #314

@vigimite
Copy link

vigimite commented Jan 6, 2020

created PR to merge master into this branch to keep this up2date, there are still 3 tests failing that i will take a look at -> #372

@ghostbuster91
Copy link
Contributor Author

Awesome, merged :) Thanks!

@adamw
Copy link
Member

adamw commented Feb 1, 2020

@zZKato do you think the current state is mergeable? Or are you maybe planning to do some more work on this? Would be great to have at least a basic implementation in the sources :)

@vigimite
Copy link

@adamw hi Adam, I don't think its mergable yet, i still think it needs a little work, however i have been super busy at work and didn't really take time to take another look at this. After my current work project is done I will take another look. I'm sorry for the delays

…preter_impl

# Conflicts:
#	build.sbt
#	project/Versions.scala
#	server/tests/src/main/scala/sttp/tapir/server/tests/ServerTests.scala
@vigimite
Copy link

vigimite commented Mar 30, 2020

@adamw @ghostbuster91 I paired on the last bit of this with a colleague of mine and I believe the implementation is now complete, there is a PR from the fork to this branch which has all the changes (we also pulled in master again) PR -> #502
EDIT: Travis build passes now

@vigimite
Copy link

The last part was a bit tricky, we ran into a couple of issues:

  1. play server doesnt support multiple headers with the same name as it uses a Map to represent it. We implemented it with the HTTP standard way of using a comma separated list, due to this there is an extra flag in the tests for play specifically
  2. in one of the test endpoints there was a cookie being used with the header name "Cookie" however according to the standard we should be using "Set-Cookie" for the response (because the input headers were returned as the response header by blazeserverbuilder so we updated the test)
  3. Play doesn't have a special request logger but we are instantiating a logger manually within the default PlayServerOptions object, is this ok or should we not log anything?

@ghostbuster91 ghostbuster91 merged commit 7ef22e1 into master Apr 1, 2020
@ghostbuster91 ghostbuster91 deleted the play_server_interpreter_impl branch April 1, 2020 20:24
@adamw
Copy link
Member

adamw commented Apr 2, 2020

Released in 0.12.28. Thanks! :)

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

Successfully merging this pull request may close these issues.

Investigate a play server interpreter
4 participants