Hi, I am trying to use the out of the box axis compression to send a gzipped message with using Axis 1.4 as per instructions outlined in http://wiki.apache.org/ws/FrontPage/Axis/GzipCompression, however the messages are to be sent to the endpoint uncompressed.
I am using Axis 1.4 with J2SE 5.0 and commons-httpclient 3.1.0 with eclipse 3.2 and websphere 6.1 all on my local dev machine. I have set up a servlet filter (/*) to intercept and log the incoming web service calls at the endpoint *prior* to the axis listener (which it does according to my stacktrace), hence prior to any decompression. The extracted InputStream message is the readable SOAP message that I sent through - I would assume gzip compression would render my message unreadable by the human eye..?? Is this a known issue of sorts,or perhaps a library version interoperability problem, or am I just missing something? To assist I can report the following:: I added the Axis 1.4 and commons-httpclient 3.1.0 sources to my workspace as eclipse projects and stepped through them. I can cofirm that CommonsHttpSender is correctly determining MC_GZIP_REQUEST and creating the GzipMessageRequestEntity as required, and that the contents of the GZipOutputStream are created and flushed to the enclosing ChunkedOutputStream as required. However, in the method writeRequestBody(HttpState state, HttpConnection conn) of class EntityEnclosingMethod (line 463) it appears that these compressed ChunkedOutputStream contents are not flushed to its encapsulating BufferedOutputStream (which writes directly to the endpoint socket) - instead the BufferedOutputStream flushes its original data (vanilla soap document) to the endpoint. Thanks in adavnce, Damian Phillips --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
