File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Tomcat and the fly likes write object to http-request Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of JavaScript Promises Essentials this week in the JavaScript forum!
JavaRanch » Java Forums » Products » Tomcat
Bookmark "write object to http-request" Watch "write object to http-request" New topic
Author

write object to http-request

Michael Oberleitner
Greenhorn

Joined: Jul 13, 2011
Posts: 16
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
Sheriff

Joined: Oct 27, 2005
Posts: 19755
    
  20

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.


SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6
How To Ask Questions How To Answer Questions
William Brogden
Author and all-around good cowpoke
Rancher

Joined: Mar 22, 2000
Posts: 12821
    
    5
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
Sheriff

Joined: Oct 27, 2005
Posts: 19755
    
  20

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

Joined: Jul 13, 2011
Posts: 16
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
Sheriff

Joined: Oct 27, 2005
Posts: 19755
    
  20

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
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16228
    
  21

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.
Michael Oberleitner
Greenhorn

Joined: Jul 13, 2011
Posts: 16
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
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16228
    
  21

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
Greenhorn

Joined: Jul 13, 2011
Posts: 16
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
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61594
    
  67

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.


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16228
    
  21

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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: write object to http-request