On Sat, Oct 3, 2009 at 6:48 PM, Vladimir Okhotnikov <[email protected]> wrote: > > 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.
We do this for other data formats that offers multiple choices. For example Bindy, XStream etc. I like option #3 as we can add additional compression methods on the fly. All what is needed is an enum with the choices. But it may be a bit weird doing .unmarshal().compress() to do de-compressing :) So maybe .compression() is a better name for it? But is that much different that .unmarshal().zip() as it will also de-compress using zip. For now I like option #3 the best. > > What do you think? > > > Claus Ibsen-2 wrote: >> >> On Sat, Oct 3, 2009 at 12:29 AM, Vladimir Okhotnikov >> <[email protected]> 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. > > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus
