write object to http-request

[Michael Oberleitner]

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...

Kind regards,
Michael

[Rob Spoor]

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.

[William Brogden]

Why are you trying to use a request attribute?

Why not just send the serialized object in the body of a POST and use javax.servlet.ServletRequest.getInputStream to read the object?

Bill

[Rob Spoor]

Hmm yeah, that is a lot easier than encoding (and then again decoding) the bytes.

[Michael Oberleitner]

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.

Kind regards,
Michael

[Rob Spoor]

Use setEntity in combination with a SerializableEntity. That way you don't even have to do the serializing yourself on the client side. Otherwise you can use a ByteArrayEntity.

[Tim Holloway]

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?

[Michael Oberleitner]

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?

Kind regards,
michael

[Tim Holloway]

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.

When serializing data from a smart web page to/from a J2EE server, probably the 2 most common formats for serialization as text are XML and JSON. XML, is of course, well-known, and JSON has the advantage that the JavaScript services of the typical web browser can easily exploit it. Which, considering that JSON stands for "JavaScript Object Notation" isn't surprising.

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.

[Michael Oberleitner]

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.

[Bear Bibeault]

XML is a nightmare.

You can use JSON in a pure Java environment with no browser or JavaScript in sight as there are plenty of JSON Java implementations to choose from (Gson, Jackson, Stringtree, etc).

The big advantage JSON has is that there's usually little to no mapping necessary. Objects can be serialized to JSON and back without the need for JAXB-type goop.

[Tim Holloway]

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.

I'm not quite as dogmatic as Bear on XML. It has its place. XML is self-descriptive, if verbose, and support is built into current JVMs. The "little to no mapping" for JSON is not always an advantage, because what that really means is that the translated data is neither type-safe nor class-structured - you're basically dealing with the same issues as you have with languages like JavaScript, where "Git 'R Dun" replaces rigorous design and compile-time checking. Which is to say that the development/support workload shifts from front-heavy (coding time) to back-heavy (run time).

I use XML. I use JSON. Depends on the need.