This produces a lot of unneeded clutter in the logs (VCards for example really fill up logs fast this way). In almost all cases, the only relevant data (to, from, id, child element name) is in the first and second element of the packet. Could we have only those lines logged, instead of the entire packet?
org.xmpp.packet.Packet#toString() returns strings that are ‘‘pretty printed’’, so a quick solution would be to scan for linebreaks (or greater-than characters).
An alternative would be to log the relevant attributes from the packet. This would be somewhat cleaner, as you have better control over the data that’‘s going to be logged (instead of assuming it’'s on the first line).
All this could be done by adjusting the code that calls packet.toString(), or by adding a new method to org.xmpp.packet.Packet that returns only the first element (or another combination of relevant data).
I understand your frustration, endlessly filling log files with that kind of data can be a nightmare. However, (only speaking for myself here), the general nature of exceptions require as much data as possible to allow analysis. Packets can contain many different things, so limiting the toString() to what may be appropriate in one use case, may not be that applicable generally.
An coding alternative would be to look at where the exceptions are occurring and deciding if it would be more useful to limit the output at that point. Given that none of the developers have replied, the case is probably not yet made for this change.
I think you’‘re absolutely right in the general sense. I probably didn’‘t emphasize that the traces I’'m referring to are a result of specific routing (delivering) problems. My point is that the first few lines of each packet contain enough information to sort out those specific problems (do routing classes even take in account other parameters than the to/from/id attributes?)
I agree that overriding the toString() method isn’'t a good idea. I think adding another ‘‘toSmallerString()’’ method to that class, and using that secondary method in appropriate places only, is a better way to go.