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
Related
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.
When you have soap webservice, you can always use soapui to create test xml requests for manual interface tests. You insert you test data into the xml document and send the request to the soap provider. You can then analyse the response in soapui.
We are currently thinking about switching from soap with xml to grpc with protobuf3. Is there a test gui for grpc that offers features as described above for grpc?
I don't think the equivalent tooling is readily available, but we do continuously try to improve the state of tooling for gRPC and Protocol Buffers.
In the meantime, there is grpc_cli project that might be immediately helpful, and gives you an idea if you want to build your own similar tool.
You could use https://kreya.app, which is a gRPC GUI client, very similar to SoapUI for SOAP services (or Postman for REST services).
Disclaimer: I'm one of the authors of Kreya.
I developed a dynamic web project in eclipse java EE ide as index.jsp, when I run it on Tomcat Server7.0 server it says http://localhost:8080/filename/ something. is that what they mean by REST? or do I need Spring to run a REST ?. rest is what that comes in a url, if i provide this url in my browser it opens the file, then why I can't call it as rest service?
Restful is an architectural style that make in disposition through HTTP a number of resources under different formats, usually json, to set or retrive the ressources, simple http operations (PUT, GET, POST, and DELETE. PUT) could be used for that.
I recommend you to use JAX-RS, but here u can see how to work with rest web service with Spring:
Building a RESTful Web Service Spring
I have a very typical problem. I am using in-house developed platform which uses Jetty server and rest easy to provide a wrapper over REST framework. When they did that they made lot of tweaks for some specific scenes.
Now problem is that when I developed a REST based service with raw interfaces of rest easy and embed my jetty server in same JVM. My service can receive the request but response is always 500 server error.
I feel the in-house framework is intercepting the response doing some security validations so my response doesn't reach.
I was wondering if there is a way to use the different rest easy version and run in same JVM. I have tried to embed a jetty server and added a normal Servlet and I can access it but I can't achieve the same with my rest based servlet.
Any Idea how could I load two versions of rest easy on same JVM ?
What you can't have is two applications in the same web application context, since you are supposed to define only one class implementing javax.ws.rs.Application.
But that shouldn't be a problem, as long as classes live in different ClassLoaders. Each web application context must be in isolation of other contexts, each defining its own ClassLoader.
You can perform all kinds of class loading manipulation in Jetty: https://wiki.eclipse.org/Jetty/Reference/Jetty_Classloading
In conclusion, as long as you use different jar files of RESTEasy in each web context, you should be able to run two REST applications using different RESTEasy versions in the same JVM process.
I went through http://cxf.apache.org/docs/jax-rs-client-api.html documentation but I am still not sure which type of rest client should be used in what use cases?
Can anyone point out the use cases / constraints with examples that would help me in choosing the right client API.
CXF 3.0 implement the JAXRS 2.0 client API, it makes your code can work with other JAXRS implementation without changing anything.
But if you are still using CXF 2.x, you need to chose between the Proxy Based API and WebClient API.
The Proxy Based API is much like the CXF JAXWS Client API, you can just invoke the service from a Proxy which implement the interface of SEI. It has some shortcomings, you cannot specify the http hears or write a generic client to invoke the different JAXRS services.
With the help of CXF WebClient API, you can invoke the JAXRS services in a normal HTTP client way, which just fill the gap of Proxy Based API.
You can find more information about those clients API here.