Abgeschickt von Wolfgang am 01 April, 2004 um 11:58:07:
Antwort auf: Re: associating message parts (from layouted message) to database columns von Danko am 30 Maerz, 2004 um 11:12:23:
If I understand your solution right, your appender
does the layouting by itself? I think this is not good from the architectural point of view (i.e. one instance is responsible for layouting), but it would work without deriving a more specialized layout. I'm principally interested in using your appender, so do you serve a configuration in your download package, which uses this new feature - I can analyze? Also you told, not to support my solution, it might be possible to combine both?
Regards,
Wolfgang
: I am sorry for not answering initially.
: I do not think I will use your solution, because I implemented a different solution using wildcards @LAYOUT_1@, @LAYOUT_2@, @LAYOUT_3@ and keys layout1, 2, 3. That should solve most common problems with different columns and layouts.
: Thanks for your input anyway.
: Regards,
: Danko
: : 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