http://bugzilla.qos.ch/show_bug.cgi?id=100 ------- Comment #15 from joern@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.