Can you tell us what's the issue that you meet? I don't quite understand you question. It could be more easy if you can show us a small test case.
-- Willem Jiang Red Hat, Inc. FuseSource is now part of Red Hat Web: http://www.fusesource.com | http://www.redhat.com Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) (English) http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese) Twitter: willemjiang Weibo: 姜宁willem On Friday, December 7, 2012 at 4:38 AM, Preben.Asmussen wrote: > Hi > > Located this to be a problem introduced between 2.9.2 and 2.9.3 as a missing > CamelCharsetName property on the Exchange. > The CamelCharsetName property is not set after 2.9.2, and when > IOConverter.toInputStream is called to convert exchange body to inputstream > it uses IOHelper to get the CharsetName for the stream construction. > > Since it is not set as a property on the Exchange it uses the fallback > method getDefaultCharsetName witch returns the platform default charset. > > Seems there has been a change on 2.9.3 since documentation of charset File2 > property states : > Camel 2.9.3: this option is used to specify the encoding of the file, and > camel will set the Exchange property with Exchange.CHARSET_NAME with the > value of this option. You can use this on the consumer, to specify the > encodings of the files, which allow Camel to know the charset it should load > the file content in case the file content is being accessed. Likewise when > writing a file, you can use this option to specify which charset to write > the file as well. See further below for a examples and more important > details. > > > This must be a bug. Should I raise a jira ? > > /Preben > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/Problem-w-FTP-producer-and-charset-tp5723604p5723722.html > Sent from the Camel - Users mailing list archive at Nabble.com > (http://Nabble.com).
