@Christian, the patch you submitted requires a bit of work to be
applied to Camel. At least the "package bla;" needs to change, and
the apache license headers applied, a unit test and so forth. I could
do this part if you don't have time. However we would need a sample
HL7 message that shows the problem as well. I would appreciate if you
could address some of these issues and resubmit.
We plan to release Camel 1.6.1 and 2.0-M2 next week, btw :)
Cheers,
Hadrian
On Apr 24, 2009, at 12:09 PM, christian ohr wrote:
Hi, me again...
Another problem I came across:
when reading HL7 messages e.g. from a stream, they become unusable
after
running though a convertBodyTo(String.class) converter for further
processing.
The reason is that the converter uses the readLine() method of a
BufferedReader which splits up at "\r" and/or "\n" characters, but
then the
string is always aggregated with "\n". As HL7 segments MUST be
separated by
"\r", you need to convert all "\n" into "\r" afterwards, which is
pretty
annoying. Please also see
http://gforge.openehealth.org/gf/project/ipf/tracker/?action=TrackerItemEdit&tracker_item_id=128
I will have a closer look at it and see if I can provide a patch next
week....
cheers
Christian
http://gforge.openehealth.org/gf/project/ipf/
--
View this message in context:
http://www.nabble.com/HL7-messages-become-unusable-after-convertBodyTo%28String.class%29-tp23219748p23219748.html
Sent from the Camel - Users mailing list archive at Nabble.com.
