Abgeschickt von Wolfgang am 09 Februar, 2004 um 10:04:27:
Danko,
I've a similar problem, Magnus wrote - but I developed a solution (log4j extension with so called structured messages, that means the message part of an event can contain more information than a simple message string and the partial data can be of any type, although the message is a string.
The access to the parts, if wanted (the complete message can be used,too - the appender decides what information to use) is given by an extended pattern layout. This works with every appender, which supports a layout, because the layout have the output control.
On the original JDBCAppender this works best [e.g. following SQL-Statement: insert into CRX_JOB_LOG (JOB_ID, LOG_DATETIME, SEVERITY, LOG_LEVEL, LOG_SOURCE, DESCRIPTION) values (%m{JOB_ID},TO_DATE('%m LOG_DATE}','YYYYMMDDHH24MISS'),'%m{SEVERITY}',%m{LOG_LEVEL},'%m{LOG_SOURCE}','%m{DESCRIPTION}')]
Then I wanted to use your JDBCAppender (because of forbidden characters in %m{DESCRIPTION}. Because of having no partial layout message control, I tried to split sql statement and layoutable part by using the properties (sql - for the constant part closing with "...values(@LAYOUT_MSG@)" and the layout settings for the variable part (the values() part from the statement above. That fails for two reasons:
a) the "layouted message" gets delimited by ''
b) each ' has been escaped by an additional '
Thinking about your tip concerning Magnus' problem transfered to my environment, I see an architectural problem: more than one component will responsible for extracting partial event data.
I would please you, to give me a partition facility for the LAYOUT_MSG (maybe similar to extract keys from MDC). If you can support my idea (in any way) my example configuration would change as follows (and it would be only a configuration task):
SQL-Statement: insert into (...) values(@LAYOUT_MSG:1@,TO_DATE(@LAYOUT_MSG:2,'YYYYMMDDHH24MISS'),...,'@LAYOUT_MSG:6@','@LAYOUT_MSG:7')
ConversionPattern: %m{JOB_ID},%m{LOG_DATE},...,%m{LOG_SOURCE},%m{DESCRIPTION}
This would also prevent to replace misunderstood forbidden characters. The LAYOUT_MSG should be identical to the converted ConversionPattern and also its parts should not deliver additional characters.
It might be useful, to have control over in which parts the replacement of forbidden characters is wanted.
Additionally it would be nice to have a control property about the delimiter of the layout message parts (e.g. an additional property: LayoutedMessagePartitializerChar)
Can you imagine?
Regards,
Wolfgang