[logback-dev] [Bug 100] Serialization of objectArray in LoggingEvent does not always work

[bugzilla-daemon at pixie.qos.ch]

http://bugzilla.qos.ch/show_bug.cgi?id=100


noreply.ceki at qos.ch changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |REMIND




------- Comment #17 from noreply.ceki at 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.