[SMXCOMP-166] servicemix-http: Support for "Content-Encoding: gzip" both on the consumer and the provider side

• Type: New Feature
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Fix Version/s: servicemix-http-2009.01
• Patch Info: Patch Available
• Assignee: Adrian T. Co
• Reporter: Bartosz Kowalewski
• Created: 11/Dec/07 23:44
• Updated: 14/Feb/09 22:04
• Resolved: 19/Nov/08 20:31

Description

SMX should support compressed content (gzip/ gzip + base64 Content-Transfer-Encoding) in both providers and consumers.

The attached patch should be treated as an initial solution. The smx-http component was successfully build, all the automated tests passed. Unfortunately it only provides a part of the required functionality and what is more no additional tests for this modification were created.

The patch provides/changes:

• support for compressing/decompressing filter for the consumer servlet (external library - see JettyContextManager; order of methods called during the initialization process had to be changed to make the filter initialize correctly)
• the pom.xml file for the smx-http component (new repository and one new dependency added; the repository definition should be moved to the top-level pom.xml file; also a property for the filter version should be extracted and moved to the main pom.xml file)
• decompression inside the provider (for responses)

The scenario tested :

• SMX deploys a SOAP-enabled provider and consumer. Consumer forwards messages to the producer. The wantHeadersFromHttpIntoExchange property is set to true. The consumer receives a SOAP request with Accept-Encoding: gzip, forwards the message to the provider (leaving the header intact). The provider sends a request to an external system and receives a compressed response. The message is decompressed in the provider and send back to the consumer ...

No support for compressing messages on the provider side is implemented.

Few more comments:
I tried to conform to the checkstyle and PMD rules defined for SMX. All the automated checks passed. Unfortunately the eclipse formatter configuration provided is inconsistent with the automated maven checkstyle test (the 'throws' keyword intendation is different). Not taking the 'throws' keyword into account, the formatter aplies a correct layout, but still the code in the repository is formatted in a different way (both layouts (with throws intended manually ) make the checkstyle test pass). Not to introduce to much chaos into the patch, I had to format all of the files manually . I may have missed some whitespaces modifications while manually applying the layout. I hope there aren't many of those.