+1 to what Christopher said... but, you can save yourself some time:
http://javawebparts.sourceforge.net/
More specifically:
http://javawebparts.sourceforge.net/javadocs/javawebparts/filter/RequestRecorderFilter.html
...and to go along with that:
http://javawebparts.sourceforge.net/javadocs/javawebparts/misc/package-summary.html
I think that'll pretty much do as suggested.
Frank
--
Frank W. Zammetti
Author of "Practical Dojo Projects"
and "Practical DWR 2 Projects"
and "Practical JavaScript, DOM Scripting and Ajax Projects"
and "Practical Ajax Projects With Java Technology"
(For info: apress.com/book/search?searchterm=zammetti&act=search)
My "look ma, I have a blog too!" blog: zammetti.com/blog
Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Youssef,
On 2/18/2009 2:02 PM, Youssef Mohammed wrote:
Sorry if this not directly related to tomcat itself. I have a swing app that
communicate with backend thru a web app deployed on tomcat. For testing
purposes, we want to be able to record some http responses and later on be
able to simulate the same response when it gets the same request ( aka
simulating the web sever). All tools we could find only record requests and
simulate the client not the sever. Any help/hint is appreciated. thnx
This sounds like something you could write yourself as a relatively
simple webapp:
1. Write an HTTP recorder filter. Configure it as the first filter that
gets run for any request. Wrap the request object with one that records
the input stream coming in, say, to a file. Wrap the response with one
that records the output to another file. Your request object can link
these two files any way it wants. You probably want to do something like
use Content-Length + SHA1(request) as a key to the request that you
store for later.
2. Run your application through this filter to generate some test data.
3. Write a servlet that does nothing but read requests, hash them, look
up the "test response" from your database of responses, and dump the
response back to the client.
You'll have to watch out for a few things:
1. The recorded response is not directly playable because it includes
things like the status header, which you can't send twice. So you'll
have to record the status header and set it appropriately instead of
just writing content.
2. Similar to #1, you have to send headers using setHeader() instead of
just writing to the output stream, because the output stream is used
solely for the response body.
3. If your requests include bodies, you might want to pre-process the
requests to account for varying amounts of whitespace, etc.
In thinking about #1 and #2 above, I think a change to the "recorder" is
in order: you probably want to store the headers, status code, etc.
specially instead of just as text in your recorded file. This will make
it easier to "play back" the response.
Hope that helps,
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkmcfiwACgkQ9CaO5/Lv0PBdqQCgs8PYXOm4U6f2oD+ejQVkHvFQ
QRMAoJJCjhY8XRJX2n9tMDwjIewvtK27
=6R37
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
__________ Information from ESET Smart Security, version of virus signature
database 3865 (20090218) __________
The message was checked by ESET Smart Security.
http://www.eset.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
