Abgeschickt von Wolfgang am 29 Maerz, 2004 um 18:19:52:
Antwort auf: Re: associating message parts (from layouted message) to database columns von Danko am 21 Maerz, 2004 um 14:16:53:
Danko,
sorry for not answering earlier, but because of the long communication pause (between my initial statement and your answer, I didn't believe to get any answer from you, so I created a solution, which circumvents the problems of the original log4j jdbc appender and closed the problem tracking at this point.
At a first glance:
: Wolfgang,
: I think I understand the problem, but I do not understand your solution. Could you please send me an e-mail to discuss your suggestion.
: I assume that you have developed your own extended PatternLayout that understands this conversionPattern (ConversionPattern: %m{JOB_ID},%m{LOG_DATE},...,%m{LOG_SOURCE},%m{DESCRIPTION}).
correct. I extended the log4j pattern layout with additional attributes and an extension for the well known %m attribute, which stands for the complete message (and works also)
:Could your please send me this class and some examples?
It's not as simple as to send one class and some examples. Its part of the extended log4j architecture I integrated into our project. I'll see.
: Also, I do not understand who or what actually determines the contents of JOB_ID in %m{JOB_ID} in your example.
%m is known as the message (in plain log4j). I extended the message attribute with structures, so someone can use %m (to get the message) and e.g. %m{JOB_ID) in junction with an additional message type attribute to get the part of the message which is named "JOB_ID".
: Please contact me directy, I have difficulty to find you.
I live incognito :-)
Regards,
Wolfgang
: Kind regards,
: Danko
: : 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