Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

...

Log

...

Component

...

The

...

log:

...

component

...

logs

...

message

...

exchanges

...

to

...

the

...

underlying

...

logging

...

mechanism.

Include Page
Uses Commons Logging
Uses Commons Logging

URI format

Code Block


{include:Uses Commons Logging}

h3. URI format

{code}
log:loggingCategory[?options]
{code}

Where *loggingCategory* is the name of the logging category to use. You can append query options to the URI in the following format, {{

Where loggingCategory is the name of the logging category to use. You can append query options to the URI in the following format, ?option=value&option=value&...

...

For

...

example,

...

a

...

log

...

endpoint

...

typically

...

specifies

...

the

...

logging

...

level

...

using

...

the

...

level

...

option,

...

as

...

follows:

{
Code Block
}
log:org.apache.camel.example?level=DEBUG
{code}

The

...

default

...

logger

...

logs

...

every

...

exchange

...

(

...

regular

...

logging

...

).

...

But

...

Camel

...

also

...

ships

...

with

...

the

...

Throughput

...

logger,

...

which

...

is

...

used

...

whenever

...

the

...

groupSize

...

option

...

is

...

specified.

{:=
Tip
title
Also
a
log
in
the
DSL
}

There

is

also

a

{{

log

}}

directly

in

the

DSL,

but

it

has

a

different

purpose.

Its

meant

for

lightweight

and

human

logs.

See

more

details

at

[

LogEIP.

Options

Wiki Markup
].
{tip}

h3. Options
{div:class=confluenceTableSmall}
|| Option || Default || Type || Description ||
| {{level}} | {{INFO}} | {{String}} | Logging level to use. Possible values: {{ERROR}}, {{WARN}}, {{INFO}}, {{DEBUG}}, {{TRACE}}, {{OFF}} |
| {{marker}} | {{null}} | {{String}} | *Camel 2.9:* An optional [Marker|http://www.slf4j.org/api/org/slf4j/Marker.html] name to use. |
| {{groupSize}} | {{null}} | {{Integer}} | An integer that specifies a group size for throughput logging.|
| {{groupInterval}} | {{null}} | {{Integer}} | If specified will group message stats by this time interval (in millis) |
| {{groupDelay}} | {{0}} | {{Integer}} | Set the initial delay for stats (in millis) |
| {{groupActiveOnly}} | {{true}} | {{boolean}} | If true, will hide stats when no new messages have been received for a time interval, if false, show stats regardless of message traffic | 
{div}
*

note

...

:

...

groupDelay

...

and

...

groupActiveOnly

...

are

...

only

...

applicable

...

when

...

using groupInterval

Formatting

The log formats the execution of exchanges to log lines.
By default, the log uses LogFormatter to format the log output, where LogFormatter has the following options:

Wiki Markup
{div groupInterval



h3. Formatting
The log formats the execution of exchanges to log lines. 
By default, the log uses {{LogFormatter}} to format the log output, where {{LogFormatter}} has the following options:
{div:class=confluenceTableSmall}
|| Option || Default || Description ||
| {{showAll}} | {{false}} | Quick option for turning all options on. (multiline, maxChars has to be manually set if to be used) |
| {{showExchangeId}} | {{false}} | Show the unique exchange ID. |
| {{showExchangePattern}} | {{true}} | Shows the Message Exchange Pattern (or MEP for short). |
| {{showProperties}} | {{false}} | Show the exchange properties. |
| {{showHeaders}} | {{false}} | Show the In message headers. |
| {{skipBodyLineSeparator}} | {{true}} | *Camel 2.12.2:* Whether to skip line separators when logging the message body. This allows to log the message body in one line, setting this option to {{false}} will preserve any line separators from the body, which then will log the body _as is_. |
| {{showBodyType}} | {{true}} | Show the In body Java type. |
| {{showBody}} | {{true}} | Show the In body. |
| {{showOut}} | {{false}} | If the exchange has an Out message, show the Out message. |
| {{showException}} | {{false}} | If the exchange has an exception, show the exception message (no stack trace). |
| {{showCaughtException}} | {{false}} | If the exchange has a caught exception, show the exception message (no stack trace). A caught exception is stored as a property on the exchange (using the key {{Exchange.EXCEPTION_CAUGHT}}) and for instance a {{doCatch}} can catch exceptions. See [Try Catch Finally]. |
| {{showStackTrace}} | {{false}} | Show the stack trace, if an exchange has an exception. Only effective if one of {{showAll}}, {{showException}} or {{showCaughtException}} are enabled. | 
| {{showFiles}} | {{false}} | *Camel 2.9:* Whether Camel should show file bodies or not (eg such as java.io.File). | 
| {{showFuture}} | {{false}} | Whether Camel should show {{java.util.concurrent.Future}} bodies or not. If enabled Camel could potentially wait until the {{Future}} task is done. Will by default not wait. |
| {{showStreams}} | {{false}} | *Camel 2.8:* Whether Camel should show stream bodies or not (eg such as java.io.InputStream). Beware if you enable this option then you may not be able later to access the message body as the stream have already been read by this logger. To remedy this you will have to use [Stream Caching]. | 
| {{multiline}} | {{false}} | If {{true}}, each piece of information is logged on a new line. |
| {{maxChars}} | | Limits the number of characters logged per line. The default value is {{10000}} from *Camel 2.9* onwards. |
{div}

{
:=
Tip
title
Logging
stream
bodies
}

For

older

versions

of

Camel

that

do

not

support

the

showFiles

or

showStreams

properties

above,

you

can

set

the

following

property

instead

on

the

[

CamelContext

]

to

log

both

stream

and

file

bodies:

{

Code Block
}

camelContext.getProperties().put(Exchange.LOG_DEBUG_BODY_STREAMS, true);

Regular logger sample

In the route below we log the incoming orders at DEBUG level before the order is processed:

Code Block
java
java
{code}
{tip}


h3. Regular logger sample
In the route below we log the incoming orders at {{DEBUG}} level before the order is processed:
{code:java}
from("activemq:orders").to("log:com.mycompany.order?level=DEBUG").to("bean:processOrder");
{code}

Or

...

using

...

Spring

...

XML

...

to

...

define

...

the

...

route:

Code Block
xml
xml

{code:xml}
  <route>
    <from uri="activemq:orders"/>
    <to uri="log:com.mycompany.order?level=DEBUG"/>
    <to uri="bean:processOrder"/>
  </route> 
{code}

h3. Regular logger with formatter sample
In the route below we log the incoming orders at {{INFO}} level before the order is processed.
{code:java}

Regular logger with formatter sample

In the route below we log the incoming orders at INFO level before the order is processed.

Code Block
java
java
from("activemq:orders").
    to("log:com.mycompany.order?showAll=true&multiline=true").to("bean:processOrder");
{code}

h3. Throughput logger with groupSize sample
In the route below we log the throughput of the incoming orders at {{DEBUG}} level grouped by 

Throughput logger with groupSize sample

In the route below we log the throughput of the incoming orders at DEBUG level grouped by 10 messages.

Code Block
java
java
10 messages.
{code:java}
from("activemq:orders").
    to("log:com.mycompany.order?level=DEBUG&groupSize=10").to("bean:processOrder");
{code}

h3. Throughput logger with groupInterval sample

This route will result in message stats logged every 10s, with an initial 60s delay and stats should be displayed even if there isn't any message traffic.

{code:java}

Throughput logger with groupInterval sample

This route will result in message stats logged every 10s, with an initial 60s delay and stats should be displayed even if there isn't any message traffic.

Code Block
java
java
from("activemq:orders").
to("log:com.mycompany.order?level=DEBUG&groupInterval=10000&groupDelay=60000&groupActiveOnly=false").to("bean:processOrder");
{code}

The

...

following

...

will

...

be

...

logged:

{
Code Block
}
"Received: 1000 new messages, with total 2000 so far. Last group took: 10000 millis which is: 100 messages per second. average: 100"
{code}

h3. Full customization of the logging output

*Available as of Camel 2.11*

With the options outlined in the [#Formatting] section, you can control much of the output of the logger. However, log lines will always follow this structure:

{code}

Full customization of the logging output

Available as of Camel 2.11

With the options outlined in the #Formatting section, you can control much of the output of the logger. However, log lines will always follow this structure:

Code Block
Exchange[Id:ID-machine-local-50656-1234567901234-1-2, ExchangePattern:InOut, 
Properties:{CamelToEndpoint=log://org.apache.camel.component.log.TEST?showAll=true, 
CamelCreatedTimestamp=Thu Mar 28 00:00:00 WET 2013}, 
Headers:{breadcrumbId=ID-machine-local-50656-1234567901234-1-1}, BodyType:String, Body:Hello World, Out: null]
{code}

This

...

format

...

is

...

unsuitable

...

in

...

some

...

cases,

...

perhaps

...

because

...

you

...

need

...

to...

...

  • ...

...

  • filter

...

  • the

...

  • headers

...

  • and

...

  • properties

...

  • that

...

  • are

...

  • printed,

...

  • to

...

  • strike

...

  • a

...

  • balance

...

  • between

...

  • insight

...

  • and

...

  • verbosity.

...

  • ...

...

  • adjust

...

  • the

...

  • log

...

  • message

...

  • to

...

  • whatever

...

  • you

...

  • deem

...

  • most

...

  • readable.

...

  • ...

...

  • tailor

...

  • log

...

  • messages

...

  • for

...

  • digestion

...

  • by

...

  • log

...

  • mining

...

  • systems,

...

  • e.g.

...

  • Splunk.

...

  • ...

...

  • print

...

  • specific

...

  • body

...

  • types

...

  • differently.

...

  • ...

...

  • etc.

...

Whenever

...

you

...

require

...

absolute

...

customization,

...

you

...

can

...

create

...

a

...

class

...

that

...

implements

...

the ExchangeFormatter interface. Within the format(Exchange) method you have access to the full Exchange, so you can select and extract the precise information you need, format it in a custom manner and return it. The return value will become the final log message.

You can have the Log component pick up your custom ExchangeFormatter in either of two ways:

Explicitly instantiating the LogComponent in your Registry:

Code Block
 [{{ExchangeFormatter}}|http://camel.apache.org/maven/current/camel-core/apidocs/org/apache/camel/spi/ExchangeFormatter.html] interface. Within the {{format(Exchange)}} method you have access to the full Exchange, so you can select and extract the precise information you need, format it in a custom manner and return it. The return value will become the final log message.

You can have the Log component pick up your custom {{ExchangeFormatter}} in either of two ways:

*Explicitly instantiating the LogComponent in your Registry:*

{code}
<bean name="log" class="org.apache.camel.component.log.LogComponent">
   <property name="exchangeFormatter" ref="myCustomFormatter" />
</bean>
{code}

*Convention over configuration:*

Simply by registering a bean with the name {{logFormatter}}; the Log Component is intelligent enough to pick it up automatically.

{code}

Convention over configuration:

Simply by registering a bean with the name logFormatter; the Log Component is intelligent enough to pick it up automatically.

Code Block
<bean name="logFormatter" class="com.xyz.MyCustomExchangeFormatter" />
{code}

NOTE:

...

the

...

ExchangeFormatter

...

gets

...

applied

...

to

...

all

...

Log

...

endpoints

...

within

...

that

...

Camel

...

Context

...

.

...

If

...

you

...

need

...

different

...

ExchangeFormatters

...

for

...

different

...

endpoints,

...

just

...

instantiate

...

the

...

LogComponent

...

as

...

many

...

times

...

as

...

needed,

...

and

...

use

...

the

...

relevant

...

bean

...

name

...

as

...

the

...

endpoint

...

prefix.

...

From

...

Camel

...

2.11.2/2.12

...

onwards

...

when

...

using

...

a

...

custom

...

log

...

formatter,

...

you

...

can

...

specify

...

parameters

...

in

...

the

...

log

...

uri,

...

which

...

gets

...

configured

...

on

...

the

...

custom

...

log

...

formatter.

...

Though

...

when

...

you

...

do

...

that

...

you

...

should

...

define

...

the

...

"logForamtter"

...

as

...

prototype

...

scoped

...

so

...

its

...

not

...

shared

...

if

...

you

...

have

...

different

...

parameters,

...

eg:

{
Code Block
}
<bean name="logFormatter" class="com.xyz.MyCustomExchangeFormatter" scope="prototype"/>
{code}

And

...

then

...

we

...

can

...

have

...

Camel

...

routes

...

using

...

the

...

log

...

uri

...

with

...

different

...

options:

{
Code Block
}
<to uri="log:foo?param1=foo&amp;param2=100"/>
...
<to uri="log:bar?param1=bar&amp;param2=200"/>
{code}

{include:Endpoint See Also}
* [Tracer]
* [How do I use log4j]
* [How do I use Java 1.4 logging]
* [LogEIP] for using {{log}} directly in the DSL for human 
Include Page
Endpoint See Also
Endpoint See Also