servicemix-http: Support for "Content-Encoding: gzip" both on the consumer and
the provider side
------------------------------------------------------------------------------------------------
Key: SM-1167
URL: https://issues.apache.org/activemq/browse/SM-1167
Project: ServiceMix
Issue Type: New Feature
Reporter: Bartosz Kowalewski
Attachments: servicemix-http.patch
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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
