[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





------- Comment #15 from joern at huxhorn.de  2008-03-13 21:52 -------
Yes, using read/writeObject instead of read/writeUTF would solve the acute
capping problem.

I'm not sure about serializing anything else but String arguments.

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.

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 ).

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.

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.

This would effectively remove the reason to change the old serialization code
at all. The whole reason for this bug would vanish.
(I'd still suggest to set formattedMessage transient and initialize it lazily.)

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.


-- 
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.