Is akka-http fully compatible with spray-routing DSL? (my service is fully implemented in spray-routing trying to understand how seamless is migration (hopefully just dependency changing)
Is it production ready?
Can it run on tomcat like spray has Servlet30ConnectorServlet
Is there an example of how to run akka-http on tomcat container with similar Servlet30ConnectorServlet
No see https://www.linkedin.com/grp/post/746917-5967985951106945028
Not of this date yet the only package exist is akka-http-experimental but it appears it should be there soon.
No
Only by using tomcat as a simple start/stop for the akka-http service
Related
Is there a Scala client library for Apache OpenWhisk?
The short answer is that there isn’t an Apache community supported Scala client. There is quite a bit to seed such an implementation from the Scala REST and CLI bindings defined by this interface https://github.com/apache/openwhisk/blob/fcbe9ca83829f2194b47f7c61a166396838c6a44/tests/src/test/scala/common/WskOperations.scala#L163 but it is not a standalone client.
If it’s something you’re interested in contributing to the project and community, you should reach out on the Apache project dev list as noted in one of the comments above.
https://docs.spring.io/spring-boot/docs/current/reference/html/howto-embedded-web-servers.html
Spring boot allows changing the web server, other than the embedded Tomcat server. Does Vertx provide similar capability?
Vert.x is implemented over netty (A lightweight event-driven network application framework).
Under the hood, starting a Vert.x HttpServer bootstraps a Netty server by default: meaning you cannot switch to another implementation.
While it should be possible to use Vertx with any web server, Vertx comes with a HttpServer in the Vert.x-Web package that can deliver static files and has routing options, role and security features and many more.
All of these are optional, yet pretty easy to use/implement if you follow the documentation. Also see all the other available modules.
If you use the Vertx webserver module you don't need a container like Tomcat, you can deploy a fat-jar and start that like any java application.
You could as well use nginx as a reverse proxy in front of vertx. This setup gives you more flexibility and you can use the full power of nginx for serving static files, your ssl configuration, gziping etc.
At the time I write this post, Play Framework is at v2.6.0-M4. The v2.5 version of the framework had difficulties to work with gRPC because of Netty conflicts (see this stackoverflow answer).
I'm starting to look into gRPC and protobufs. Already ported a project from Play Framework 2.5 > 2.6.0-M4 in anticipation of the actual release. Currently I have some questions regarding integration of gRPC. I'm wondering how to let the gRPC server work along nicely with Play Framework. I know that v2.6 switched to Akka HTTP server instead of Netty, while I use the grpc-netty dependency in sbt so maybe I'll have to switch the project to Netty again (here's how).
For testing purposes, I created a quick and dirty GrpcServer.scala class that starts up a thread with the GrpcServer listening. I managed to add ScalaPB with gRPC and generate/compile my protobufs. It works perfectly to communicate with a small testing NodeJS app but I have to startup this server app independently from the main project:
private def start(): Unit = {
server = ServerBuilder.forPort(GrpcServer.port).addService(GreeterGrpc.bindService(new GreeterImpl, executionContext)).build.start
GrpcServer.logger.info("Server started, listening on " + GrpcServer.port)
sys.addShutdownHook {
System.err.println("*** shutting down gRPC server")
self.stop()
System.err.println("*** server shut down")
}
}
Possible solutions to integrate gRPC in Play Framework
Now for the real integration in Play Framework v2.6, I'm looking for suggestions. Here's some things I can do:
Create a module and start the gRPC server when Play Framework starts up, like described in this stackoverflow answer. This would mean that we run the gRPC server on a different port next to the existing server (Akka HTTP server from Play Framework 2.6)
Create a Scala Command and make it long-running. So we always make sure we start a command that runs the gRPC server when we start our application on a server.
Switch from Akka HTTP to Netty in Play Framework v2.6 and tightly integrate gRPC with the existing Netty server so it hooks into the existing Netty server instead of creating a server on our own. I would like this solution but not sure how to deal with it. It certainly would avoid having two separate http stacks running.
Any tips/ideas for a clean integration are helpful as there's not much information about Play Framework and gRPC available, except that there were issues in the previous 2.5 version...
I have a fairly simple jax-rs application running on wildfly 9. It makes use of resteasy multipart form. It runs 100%. Now I am trying to run the same application with wildfly swarm, but get a
javax.ws.rs.NotSupportedException: Could not find message body reader for type .... multipart/form-data on execute of the resource post operation.
This as far as I understand is the resteasy-multipart-provider. In my pom I have the wildfly-swarm-weld-jaxrs fraction. Is this not suppose to take care of the multipart features? If not how do I get it included in the swarm fat jar/package? I have tried including the resteasy-multipart-provider as a compile dependency, but this breaks the swarm application and it refuses to start/boot. Or have I missed something else?
JAX-RS Multipart support is declared as an optional module in WildFly, so the necessary classes to make it work were not included in the application.
Since then Ken Finnigan added a new WildFly Swarm API for the module.
If you build the latest from wildfly-swarm/wildfly-swarm on GitHub you can add the wildfly-swarm-jaxrs-multipart artifact as a dependency to the project and that should resolve the problem.
I have a webservice running on jboss server. I can't change it to netty because i'm using other features of jboss. But i want to use finagles futures from the client. Is there a way ?
The Future class used in Finagle is part of Twitter's util project, which is open source. com.twitter.util.Future is usable on its own within any project that adds util-core as a dependency.
You can always use a finagle client to make calls to an HTTP [or other RPC protocol] webservice. It doesn't matter how the service is implemented as along as it uses the protocol correctly. If you are using Java, this link should give you details on how to build a finagle client for an HTTP service: https://github.com/twitter/finagle#Building%20a%20Client%20in%20Java
Here's some sample code to for a more elaborate finagle HTTP client: https://github.com/twitter/finagle/blob/master/finagle-example/src/main/scala/com/twitter/finagle/example/http/HttpClient.scala