camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Okhotnikov <vokhotni...@gmail.com>
Subject Re: Zip format problem
Date Sat, 03 Oct 2009 16:48:58 GMT

Thank both you and Hadrian for your responses. I'm actually willing to
provide a patch to add support for real zip data format, but I need your
advice about particular route to take. So far, I see 3 options:

1. unmarshal().zip(ZipMethod.Zip)
+: backward compatible (if zip() is equivalent to zip(ZipMethod.Deflate)
-: lacks integrity, since there is also gzip format as well

2. rename current zip() to deflate(), add zip() which uses correct method
+: consistent with other data formats
-: not backward-compatible

3. deprecate zip() and gzip(), replace them with
compress(CompressionMethod.Zip) etc.
+: backward compatible, reasonably consistent
-: still treats compression data formats as a subcategory of data formats
interface-wize, which may not be desirable.

What do you think?


Claus Ibsen-2 wrote:
> 
> On Sat, Oct 3, 2009 at 12:29 AM, Vladimir Okhotnikov
> <vokhotnikov@gmail.com> wrote:
>> Apparently I have a small problem with a ZIP data format. In my project,
>> I
>> have to download zipped files from FTP, uncompress and process them. So,
>> I
>> guess the route should be like:
>>  from("ftp://...").unmarshal().zip().to(...)
>> While writing a test for that particular route, I've created a small test
>> zip file and tried to process it - with no luck - all I got was the
>> ZipException "unknown compression method"
>>
>> I also tried feeding the actual zip file from the FTP, with the same
>> result.
>>
>> Eventually I looked at the code, and found that zip data format
>> processing
>> is being done by org.apache.camel.impl.ZipDataFormat class. What's
>> strange
>> is that the class uses java.zip.InflaterOutputStream (and its
>> DeflaterOutputStream counterpart). Now, by no means I'm an expert in
>> compression methods, but the java API docs claims that those classes use
>> "deflate" method, not "zip". For "zip" method I think ZipInputStream must
>> be
>> used instead?
>>
> 
> Yeah the person who submitted this data format wrote it in that way
> and it was branded zip from the start.
> Its meant for e.g. text/xml payloads to be compressed / decompressed
> for example over http.
> 
> You are welcome to take a look if you can enhance it and offer an
> option to select which "mode" to use.
> 
> -- 
> Claus Ibsen
> Apache Camel Committer
> 
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
> 
> 

-- 
View this message in context: http://www.nabble.com/Zip-format-problem-tp25723682p25730470.html
Sent from the Camel - Users mailing list archive at Nabble.com.


Mime
View raw message