You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Seon Lee <fu...@gmail.com> on 2008/06/16 17:01:06 UTC
Re: Is there a WIKI page describing class type returned by
getBody() method ?
Ive been looking for an easy way to debug the header contents on messages
passed around in Camel. The ideas in this thread for a new feature are
great.
Until then, what is the best way to dump/debug message headers currently
with release 1.3 of Camel? I poked around and it looks like I could create a
custom component that performs this logging. Are there other alternatives?
Thanks, and cheers!
Seon Lee
James.Strachan wrote:
>
> On 17/04/2008, Roman Kalukiewicz <ro...@gmail.com> wrote:
>> 2008/4/17, James Strachan <ja...@gmail.com>:
>>
>> > > >> According to this approach, the user is required to modify its
>> CamelRoute
>> > > >> by adding :
>> > > .to("log:loggingCategory?level=DEBUG")
>> > > I thinkh that this appraoch is a little bit invasive.
>> > > It should be better to have a static Trace method defined at the
>> level of
>> > > the CamelContext that we can activate or desactivate in the
>> configure()
>> > > method in order to produce INFO, ERROR or DEBUG information and of
>> course
>> > > generate the required information like the Body class type
>> returned, headers
>> > > info, ... ?
>> >
>> >
>> > Great idea! :)
>> >
>> > I guess there's a few different things we could trace...
>> >
>> > * all the exchange properties
>> > * all the message properties
>> > * the message headers
>> > * the message body type
>> > * the message body
>> >
>> > I wonder if we should always just log all of it; or have a few
>> > levels/categories of debug/trace logging so folks can do a less noisy
>> > log?
>>
>>
>> Maybe we should simply have a LogProcessor that has an Expression as a
>> parameter and logs the value of this expression? This guy could be
>> reused by log endpoint then. We could have few predefined log
>> categories (that maps to certain Expression) and an ability to
>> reference an expression by a bean name maybe like
>> log:logger?expression=myExpressionBean
>>
>> Moreover I believe that we should have something like
>> trace(Expression) method on RouteBuilder type.
>
> Great idea! :)
>
> I guess we could easily install the logging via an interceptor. So at
> the top of your DSL you could add a logging interceptor which would be
> applied to all routes etc.
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://open.iona.com
>
>
--
View this message in context: http://www.nabble.com/Is-there-a-WIKI-page-describing-class-type-returned-by-getBody%28%29-method---tp16677652s22882p17866374.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Is there a WIKI page describing class type returned by
getBody() method ?
Posted by Seon Lee <fu...@gmail.com>.
I tried using the log component (log:category?level=...) however it only
displayed the object identifier and no information on the body or the
header.
I'll check out the debugger another time, it looks like a good start. For
now, I've resorted to using a quick bean route using a simple class like
this:
public static class LogBean
{
public void doSomething(@Headers Map<String,Object> headers, @Body
String body) {
log.debug("headers=>"+headers);
}
}
BTW, I am using commons-logging with log4j. I don't know if this affects the
output of the log component.
Cheers!
Seon Lee
James.Strachan wrote:
>
> I often modify a route like this...
>
> from(...)
> to("log:Foo").
> to(...);
>
>
> to add an extra
>
> from(...)
> to("log:Foo").
> to(...);
>
> route to add more logging. Or turn debug logging high. Or sometimes
> when things are wacky I add a custom processor...
>
>
> from(...)
> process(new Processor() {
> public void process(Exchange) {
> // set a break point here!
> }
> ).
> to(...);
>
> So I can easily set a breakpoint and look at the exchange / message /
> headers / body etc.
>
> We need to make this a bit simpler though!
>
> FWIW I've an experimental debugger framework...
> http://activemq.apache.org/camel/debugger.html
>
> which can be enabled which then adds an interceptor which can record
> the exchanges passed into each step of a route and can trace them etc.
> Its kinda early days and could use some love; but its a kinda start
> along the road to having a better framework for diagnosing things
> going wrong mid-route etc.
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://open.iona.com
>
>
--
View this message in context: http://www.nabble.com/Is-there-a-WIKI-page-describing-class-type-returned-by-getBody%28%29-method---tp16677652s22882p17870016.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Is there a WIKI page describing class type returned by getBody() method ?
Posted by James Strachan <ja...@gmail.com>.
2008/6/16 Seon Lee <fu...@gmail.com>:
>
> Ive been looking for an easy way to debug the header contents on messages
> passed around in Camel. The ideas in this thread for a new feature are
> great.
>
> Until then, what is the best way to dump/debug message headers currently
> with release 1.3 of Camel? I poked around and it looks like I could create a
> custom component that performs this logging. Are there other alternatives?
I often modify a route like this...
from(...)
to("log:Foo").
to(...);
to add an extra
from(...)
to("log:Foo").
to(...);
route to add more logging. Or turn debug logging high. Or sometimes
when things are wacky I add a custom processor...
from(...)
process(new Processor() {
public void process(Exchange) {
// set a break point here!
}
).
to(...);
So I can easily set a breakpoint and look at the exchange / message /
headers / body etc.
We need to make this a bit simpler though!
FWIW I've an experimental debugger framework...
http://activemq.apache.org/camel/debugger.html
which can be enabled which then adds an interceptor which can record
the exchanges passed into each step of a route and can trace them etc.
Its kinda early days and could use some love; but its a kinda start
along the road to having a better framework for diagnosing things
going wrong mid-route etc.
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://open.iona.com