Hmmm…. I would expect that if the character set was already on the exchange before the call, it should still be there after the call - that is the issue I hit - it was removing the CamelCharsetName exchange property that was already there. If the charset is specified on the convertBodyTo, I think it should use that charset - but is should either leave the existing CamelCharsetName there or replace it with the new value.
Any other thoughts? > On Feb 15, 2018, at 2:33 PM, Alex Dettinger <aldettin...@gmail.com> wrote: > > I would not say that it's a bug. > Actually, when convertBodyTo ends up decoding bytes to string, I would > expect the charset to be removed. > When convertBodyTo ends up encoding a string into bytes, I would expect the > charset to be overridden (I don't think that it is the current > implementation however). > > On Thu, Feb 15, 2018 at 7:38 PM, Quinn Stevenson < > qu...@pronoia-solutions.com> wrote: > >> I found a situation where Camel isn’t doing what I expected, and I wanted >> to ask the developers before I created the JIRA and changed the behavior >> that I believe is a bug. >> >> What I’m seeing is when I call convertBodyTo with a both type and a >> character set supplied and the exchange already has a character set >> specified, the character set is being removed by the convertBodyTo >> operation. I would expect the original character set on the exchange would >> be restored, not removed. >> >> Is this functionality by design or is it a bug? >> >> >> >> >>
