Hi
These spring to my mind:
- choice
- filter
- interceptor (kinda lika AOP around)
- processor (code in plain java as you like)
Choice and filter use the DSL where you can use a predicate to test for null
bodies.
From("xxx").choice()
.when().body().isNull().to("yyy")
.otherwise().to("zzz")
In the processor you can detect if the body is null and do something
Where do you need to detect the "null body"?
But check out if the above suites your needs
Med venlig hilsen
Claus Ibsen
......................................
Silverbullet
Skovsgårdsvænget 21
8362 Hørning
Tlf. +45 2962 7576
Web: www.silverbullet.dk
-----Original Message-----
From: raulvk.soa [mailto:[EMAIL PROTECTED]
Sent: 23. september 2008 13:19
To: camel-user@activemq.apache.org
Subject: RE: Bug in LogFormatter.getBodyTypeAsString
Hi Claus,
Thanks for the info. I wasn't aware that you had already detected this.
Actually, my use case is a bit different. I need to detect when the body is
null and take action when that happens. Does anything come to mind as to
what kind of Expression should I use?
Thanks!
Claus Ibsen wrote:
>
> Hi
>
> Yes unfortunately the bug is the 1.4.0 release.
>
> I have added it to known issues in the release notes, with a workaround:
> http://activemq.apache.org/camel/camel-140-release.html (currently only
> showing for tracer but the same workaround applies)
>
> It is of course fixed in the next 1.5 release (work in progress)
>
>
> Med venlig hilsen
>
> Claus Ibsen
> ......................................
> Silverbullet
> Skovsgårdsvænget 21
> 8362 Hørning
> Tlf. +45 2962 7576
> Web: www.silverbullet.dk
>
> -----Original Message-----
> From: raulvk.soa [mailto:[EMAIL PROTECTED]
> Sent: 23. september 2008 12:59
> To: camel-user@activemq.apache.org
> Subject: Bug in LogFormatter.getBodyTypeAsString
>
>
> Hi,
>
> Sometimes, the "in" message of an exchange can be null. I have come across
> such case when communicating over a JBI endpoint, and during the
> processing
> within ServiceMix an internal error occurs. JBI returns a null "out"
> message
> on an InOut exchange, and Camel's Pipeline takes this null "out" message
> and
> sets it as the new "in" message, thus effectively setting the "in" message
> as null.
>
> If the next endpoint is a Log component, this is what happens:
>
> 11:48:29,396 | ERROR - org.apache.camel.processor.Logger - Failed delivery
> for exchangeId: ID-XXX-B624E47AF0/4985-1222164544269/0-172. On delivery
> attempt: 5 caught: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.camel.component.log.LogFormatter.getBodyTypeAsString(LogFormatter.java:167)
> at
> org.apache.camel.component.log.LogFormatter.format(LogFormatter.java:56)
> at org.apache.camel.processor.Logger.logMessage(Logger.java:218)
> at org.apache.camel.processor.Logger.process(Logger.java:88)
> ................
>
> I believe that logging methods should be non-intrusive, so we should first
> check whether variables are null before accessing them, as it is not
> acceptable for a logging task to interrupt the pipeline. In this case, my
> suggestion is that if BodyType == null, then just print the string
> "BodyType: null".
>
> Cheers.
> --
> View this message in context:
> http://www.nabble.com/Bug-in-LogFormatter.getBodyTypeAsString-tp19625342s22882p19625342.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
>
--
View this message in context:
http://www.nabble.com/Bug-in-LogFormatter.getBodyTypeAsString-tp19625342s22882p19625600.html
Sent from the Camel - Users mailing list archive at Nabble.com.
