This week's book giveaway is in the OCAJP forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide 1Z0-808 and have Jeanne Boyarsky & Scott Selikoff on-line! See this thread for details.
Hello I need to send a java object in a http-request to a java servlet.
In the HttpServletRequest there is the method getAttribute(String name) to do things like this, but i don't know how to set this attribute on the client side, because there is no HttpServletRequest object.
The client uses classes from the org.apache.http package, but i cannot find a way to set an object in an http request, which can be read using HttpServletRequest.getAttribute().
I hope someone can help me...
Request attributes are server side only. The only way to send data from the client to the server is through GET / POST parameters. Those handle text only though, so you would need to encode the data. One way is to serialize the object into a byte, encode that byte using something like Base64 or simple HEX encoding, then send that with URL encoding. I'd use POST though as the length of entire URLs may be limited (it certainly is in some browsers), and GET parameters become part of the URL.
Hmm yeah, that is a lot easier than encoding (and then again decoding) the bytes.
Joined: Jul 13, 2011
Thanks Rob, thanks William
Maybe I'm blind, but I'm looking for a way to write into the http post body in the org.apache.http.client.methods.HttpPost object, but i cannot find a method for this.
With org.apache.commons.httpclient.methods.PostMethod it seems to be possible, but this api i did not use so far.
On the client side, everything is text. Everything. Headers, cookies, form data, web pages, everything. Even images and videos are (MIME-encoded) text.
That's because www, like email were designed to operate in a heterogeneous ecosystem where the clients might be ASCII or EBCDIC, little-end or big-endian, 32-bit or 64-bit, and many other options besides. Text is text, however, doesn't have to worry about byte order, and coding methods (ASCII/EBCDIC) can be handled automatically without knowledge of the context.
The actual HttpRequest and HttpResponse objects in J2EE are server-side distillations of what comes from and goes to clients (respectively), along with such useful context as may get picked up along the way. They're defined as Java Interfaces, so that the internal structure and content can be customized based on what a particular J2EE container may require.
People periodically attempt to manipulate these objects directly. Generally with less-than-sterling results. In particular, attempts by application code to modify the Request attributes when running under recent versions of Tomcat will throw Exceptions. These objects do not belong to you. You are lent them, and you may query them, but their actual direct manipulation is hazardous, assuming you can manipulate them directly at all.
So much for theory. This is one of those cases where a solution has been posited but the actual problem isn't known. Rather like the aptitude tests that only work when the testee is suitably ignorant, it concentrates on a single line of attack and ignores the larger issue, which means that we cannot actually suggest workable (and often simpler) ways of handling the problem.
In other words, we need to know why it's supposed to be necessary to write to the HttpRequest to begin with. What, in actual application functionality, is the intended goal?
Customer surveys are for companies who didn't pay proper attention to begin with.
Joined: Jul 13, 2011
Hello and thanks again.
First the problem is solved with the SerializableEntity.
I need to send the object from the client to the server, because I have an application where the server has data in a key-value-store and the client should be able to load objects from the server, manipulate them and send them back.
This question here belongs to the manipulation of objects.
The objects I need to send in the request are called Node and they have a tree structure, so that the node object can have several other child node objects, but every node has just one ancestor node, except the rootnode which has no ancestor node.
The user is possible to expand the tree and make several changes, for example changing leaf values or adding nodes in arbitrarily positions.
To avoid making to many calls to the server for every change the user makes, the idea is to send the whole tree to the server and the server compares the tree with the data in the db and changes the things the user made. So I needed to serialize the tree
and put it in the http-request and this all seems to work now.
The fact that the client has just text is interesting, but a serialized java object is also just text, or?
Java serialized objects are not text. They are binary. They're also Java version-dependent, which is a massive source of headaches when using them for client/server purposes.
The J2EE Http(Servlet)Request object itself doesn't exist on the client side. It's constructed by the appserver when it parses an incoming HTTP request stream. So if you wanted to "add" client object data to the request, you'd make it part of the client request itself. You can use a hidden form field and POST as one way of doing that.
At a more application-oriented level, I should mention that I've had good results using JSF RichFaces tree control, which allows AJAX interaction at a per-node level. It was a real lifesaver for me, since without it (and AJAX), I was taking a 3MB hit each and every time the web pages updated. On a slow data link.
Joined: Jul 13, 2011
Ok that's an interesting point I haven't concerned.
I think I have to make the serialization with xml, because I don't have a browser as client, no html, but a swing client, which uses http for communication with the server.
Of course, from a traditional point of view, the preferred way for a standalone Java app to communicate with a Java server would be RMI. However, RMI uses binary serialization, meaning that versions have to be kept in sync (as mentioned earlier), and you might encounter firewall issues. Plus, RMI services can't be invoked from a web browser (without help), if you wanted that option.