The HL7 message may contains some characters that causes the logger to
not log the message. (eg the pipes and other control chars it may
contain).
I can see the same on adding some logging to the camel-hl7 unit tests.
So that may be why your "log ${body}" do not print anything.
On Sun, Jan 24, 2016 at 11:13 AM, Walzer, Thomas
<[email protected]> wrote:
> I am using Camel 2.15.2 & blueprint.
> When using to uri=„log:…“ (Log component) it shows the body-type as
> unpooledunsafedirectbytebuf. This statement works ok. And yes, it should
> contain the ack response.
> When using <log message=„*** ${body} ***“/> (or anything else that needs a
> string, like convertbodytostring, etc) I get exceptions.
> Even when the first statement after netty4 is to-file it does not work. So
> there should be no one consuming it before.
> The codecs are default.
>
>
> <bean id="hl7nettydecoder"
> class="org.apache.camel.component.hl7.HL7MLLPNettyDecoderFactory">
> </bean>
> <bean id="hl7nettyencoder"
> class="org.apache.camel.component.hl7.HL7MLLPNettyEncoderFactory">
> </bean>
>
> I will continue to strip my complex project down.
>
> Cheers, Thomas.
>
> Am 22.01.2016 um 16:04 schrieb Claus Ibsen
> <[email protected]<mailto:[email protected]>>:
>
> On Fri, Jan 22, 2016 at 3:58 PM, Walzer, Thomas
> <[email protected]<mailto:[email protected]>> wrote:
> Problem is: I have a simple example that works fine. My more elaborate
> version breaks. But basically it is:
> queue->transacted->convertbodytostring->setSomeHeaders->log->netty4->log
>
> The netty4 listening to my message gets the message and returns an ack. When
> I try to get it as a string—>it breaks.
> I do have a DefaultErrorhandler configured. But it should not kick in if
> everything works ok.
>
>
> Just to be clear. Its that last part
>
> netty4->log
>
> Where you attempt to log the netty4 response (eg the ack response) ?
>
> Do you use any special codec or encoders with netty4 or something?
> And what version of Camel do you use?
>
> When I change the netty4 endpoint to mina2 -> it works. So I assume the
> problem lies with the netty4 component. Maybe the codecs? Why do I not use
> mina2? Because ultimately I want TLS which is broken with mina2 in my version
> of Camel.
>
> It seems like some problem with redelivery as Claus suggested, however I am
> still puzzled…
>
> Cheers, Thomas.
>
> Am 22.01.2016 um 08:20 schrieb Claus Ibsen
> <[email protected]<mailto:[email protected]>>:
>
> On Tue, Jan 19, 2016 at 4:54 PM, Walzer, Thomas
> <[email protected]<mailto:[email protected]>> wrote:
> Hi,
>
> camel-2.15.2
>
> I can successfully send to a HL7-Server, however I have troubles accessing
> the resulting ACK.
> Unfortunately it is of type UnpooledUnsafeDirectByteBuf and type conversion
> to string fails:
>
> ....On delivery attempt: 2 caught: org.apache.camel.TypeConversionException:
> Error during type conversion from type: java.lang.String to the required
> type: java.lang.String with value UnpooledUnsafeDirectByteBuf(freed) due
> io.netty.util.IllegalReferenceCountException: refCnt: 0
>
>
> Sounds like you are doing redelivery and the byte buf is not reset on
> redelivery or something so the data stream becomes empty and not
> convertable to a string type. A bit like when you are not using stream
> caching
> http://camel.apache.org/why-is-my-message-body-empty.html
>
>
>
> Any ideas how to work with the ACK (besides logging which works)?
>
> Cheers, Thomas.
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com<http://davsclaus.com/> @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
