http://bugzilla.qos.ch/show_bug.cgi?id=100 noreply.ceki@qos.ch changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |REMIND ------- Comment #17 from noreply.ceki@qos.ch 2008-03-19 19:01 -------
This would require a not quite easy to implement logic. You'd have to analyze the entire contents of a Collections, probably recusively, in that case because you wouldn't have the generic information anymore... also, the arguments must never be changed in the process.
Very good point. However, there are way to constrain the problem to a more manageable issue. Assume logback is used in a large and complicated business process and we would like to track messages that are treated over several applications distributed over many machines. It would be interesting to specify parameters such as e.g. server id, application name, request id, transaction id, user id etc. The last three parameters are specific to the request being processed and presumably should be specified in the logging event as parameters. I would argue that passing those parameters in an object of type Map<String, String> makes sense. Assuming a class called LogbackEventMap which extends HashMap<String, String>, we could simplify the problem by serializing objects of type String or LogbackEventMap. This allows for flexibility without introducing much new complexity.
However, I already suggested to change the arguments to String[] instead of Object[] in bug #134 because I originally thought that arguments are only used to format messages (and optionally to extract a Throwable as in my slf4j-suggestion at http://bugzilla.slf4j.org/show_bug.cgi?id=70 ).
Well, arguments could also be used as an extension mechanism to LoggingEvent via SLF4J's API. Apart from the MDC, that's the only extension point available using the SLF4J "standard".
I just checked out the filtering-related code and realized that it would still be possible to use TurboFilters to perform a decision on the original arguments since TurboFilters are executed before the actual event creation.
I had not thought of TurboFilters. As such, it should not come as a surprise if I say that TurboFilters were not on my mind when we previously discussed the type of LoggingEvent.argumentArray.
Because of this, I think it's absolutely viable to change LoggingEvent.argumentArray to String[] and also change the signature of the getter to String[] getArgumentArray() (this method isn't used in the codebase at the moment). I'd suggest to perform the conversion from Object[] to String[] in Logger or, better yet, in some general purpose method in slf4j MessageFormatter (if my slf4j-suggestion is considered, because it would then be necessary to extract the Throwable first and return a Throwable-String[]-formattedString result with message and arguments as params because it would be necessary to at least count placeholders...) so LoggerEvent is freed of some more complexity. This would mean that the c'tor's argArray should also be changed to String[]. It's only called in Logger and test classes so this change should be easy.
At this juncture, I would like to hold on to the idea there is some purpose to keeping the type of LoggingEvent.argumentArray as Object[]. The future may prove that the idea was merely sepeculative generality. Time will tell.
I do have some general concerns about either TurboFilter or Filter working directly with arguments, though. They currently both have the ability to interact with application-level objects! This would, of course, be an error in the respective Filter but it doesn't make me feel very well about it at all. Those objects probably want to execute some logging events, too, which could lead to some nasty side effects, I fear. Probably even a deadlock.
Therefore I'd even suggest to remove params[] from the TurboFilter.decide signature to remove the risk of side-effects caused by log statements. This would mean that application-level objects are only touched by Logger which can be expected to be safe.
Those are all valid arguments assuming that LoggingEvent.argumentArray is intended only message formatting. However, as I tried to argument above, argumentArray can also be seen as a data mule extending the fields available in LoggingEvent. I would like to come to this issue in a few month after it has matured a bit more. -- Configure bugmail: http://bugzilla.qos.ch/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.