I am wondering how I can use google protocol buffers to accept a request and send a response back to a client? I am thinking about writing a servlet which will take a request.
Is the following trail of thought the correct way to implement this:
1. Have a .proto file which is the message definition for the incoming request.
2. Write a servlet which accepts this request, does various tasks like querying database
and then sends a response. Will this response require a separate .proto message definition with all the fields that make up the response?
3. Will the client just invoke the doGet() method of my servlet and pass the request, it should then return a response as a protobuff object?
Any suggestion or idea will be very much appreciated.
Typically you'd want a request message and a response message, yes. You'd also probably want a method name to describe the action - that's certainly how the built-in PB services work.
The client wouldn't invoke doGet() - it would make a request (probably a POST rather than a GET) and your servlet would receive it.
Now, ideally you could have a general "ProtocolBufferServlet" which could service the requests by handing them off to services implementing the appropriate interfaces.
I suggest you look at the documentation for Protocol Buffer services and the Java services generated code for more information. You could implement an RpcChannel which worked over servlets, or get the client to make the HTTP post directly. You'd probably use dependency injection of some kind at the server side to tell the servlet what was implementing the service.
HI,
I have this up and running. I ended up posting a http request as a post to my servlet. I was able to take the request protocol buffer, read the request, do some processing and then send back a response. It was actually really simple once I got it working. We used the 1 .proto file to define the request and response message structure.
Related
We have a legacy app that uses Java Web Services (JAX-WS) and runs on Glassfish 4.1.1. We want to implement compression of both the response and request. (We know that compressed requests can be a security risk but we are willing to accept this because the clients are all internal.) Turning on the GF setting for compression only compresses the response. If I send a compressed request body I get an error that indicates the SOAP message contained an invalid character, which tells me that GF did not decompress the request body.
Since GF won't automatically decompress the request I have been trying to modify the legacy app itself to do the decompression. I have tried the following:
A SOAP message handler. This does not work because the handler is invoked too late; at that point the unmarshalling of the SOAP message has already failed, because the unmarshaller received binary data.
A servlet filter. I tried setting up one that was invoked on any URL, but it never trips for the web service calls. I am not too familiar with the plumbing here, but it does not appear that the web service is implemented as a servlet.
My next option is to try setting up a proxy server that takes the raw request, unzips it, and forwards it to the web service.
Before I go down that path, does anyone have a simpler recommendations? Is what I'm try to do even possible? Much thanks in advance!
on my public web application running on JBoss 5 with Java 6 I need to implement something that receive an http post from another external server with some parameters (server to server call) .
The server that call me doesn't need an answer, just standard http code reponse( es 200 - OK).
Can I use a servlet for this?
If not what should I use? (I cant'use restfull or soap ws).
To my knowledge, your best bet for given situation is REST or SOAP. But you already mentioned that you cannot use that.
I don't see any reason why a servlet can't be used here. You have request & response objects in servlet doPost method. You can manipulate the response object to set appropriate response code back.
To give you a background, upon receiving a request we want to extract the payload along with other information like request URI, query parameters, etc. and put it as a message in a Message Queue. Another service will then pick messages and invoke Katharsis so that the proper Controller will process the request. This is to create an asynchronous processing mechanism.
Now to invoke Katharsis manually we need to implement KatharsisInvokerContext which requires to create HttpServletRequest and HSResponse. However, since this is happening in the server we want the response goes back the the original requester.
Does anyone know how to do this or whether we are doing it wrong way? I'm open to suggestions.
We are using Spring Boot, Katharsis-core 2.0.1 and Katharsis-spring 2.0.3.
I'm writing a server side app in Java using the HttpCore library.
I have an HttpRequest and I'm trying to get the postdata sent from a form. The problem is- when I use request.getEntity() it returns a null object, even though when I look through HTTPFox on what kind of request I'm sending the post data is clearly there.
What am I doing wrong?
There seems to be some confusion. You are sending requests from a browser to the server. The server is likely using the servlet API. There you handle requests using the doPost(..) method of an HttpServlet. You have an HttpServletRequest from which you can get the parameters - request.getParameter("paramName")
HttpCore on the other hand is used to make requests, not to handle requests. It is used as an http client (in the role of the browser).
I am trying to put some logging to capture the raw http request coming to my application. My Java code is inside a SpringMVC controller. I have access to the "HttpServletRequest" object. But I could not find a way to get the raw http request stream out of it. There is a reader but only reads the post content. What I want is the whole shebang, the url, the headers, the body. Is there an easy way to do this?
Thanks in advance.
No.
The servlet provides no such API, and it would be hard to implement because (basically) you cannot read the same data twice from a Socket. It is not difficult to get header information, but raw headers are impossible to capture within a servlet container. To get the bodies you need to capture them yourself as your application reads/writes the relevant streams.
Your alternatives are:
Write your own server-side implementation of the HTTP protocol. (Probably not right for your application.)
You may be able to get the header information you need with filters, though they don't show the raw requests.
Some servlet containers have request header logging; e.g. with Tomcat there's a beast called the RequestDumperValve that you can configure in your "server.xml" file.
Implement a proxy server that sits between the client and your "real" server.
Packet sniffing.
Which is best depends on what you are really trying to achieve.
FOLLOWUP:
If the "badness" is in the headers, the RequestDumperValve approach is probably the best for debugging. Go to the "$CATALINA_HOME/conf/server.xml" file, search for "RequestDumperValve" and uncomment the element. Then restart Tomcat. You can also do the equivalent in your webapp's "context.xml" file. The dumped requests and responses end up in "logs/catalina.out" by default. Note that this will give a LOT of output, so you don't want to do this in production ... except as a last resort.
If the badness is in the content of a POST or PUT request, you'll need to modify your application to save a copy the content as it reads it from the input stream. I'm not aware of any shortcuts for this.
Also, if you want to leave logging on for long periods, you'll probably need to solve the problem yourself by calling the HttpServletRequest API and logging headers, etc. The RequestDumperValve generates too much output, and dumps ALL requests not just the bad ones.
No, servlets provide no api to get at the raw request - you might need a sniffer like wireshark for that.
You can get at the parsed request headers and uri though:
getHeaderNames()
getRequestURI()
etc.
I managed to read my raw request in my webapplication deployed on Tomcat 5.5
All I had to do is to read HttpServletRequest through my servlet/Spring controller
using request.getInputStream() only.
It must be the first API approach to the request. before any filter or other command start to mass with the request that cause its completely reading by the webserver.
What's the problem with that approach?