Community
Participate
Working Groups
Build Identifier: I20091210-1301 When tracing a message containing pipes ('|'), the pipe is stored as-is which results in strange behavior when reading this file (I'm currently trying to write some sort of parser for trace files). The only solution that I can see is to do some sort of escaping (of course pipes might not just occur in messages, but also in Exception messages that are traced using the corresponding trace(String, String, Throwable) method). There is a similar issue with line breaks, but quite frankly, I'm not so sure about the correct solution; I managed to write some logic that can deal with this, but I haven't played around with all the possible combinations of /n and /r yet... Reproducible: Always Steps to Reproduce: 1. Activate tracing for some location 2. call trace(<your location>, "A message with a pipe | here"); 3. Observe the entry in the file
Created attachment 158082 [details] Example trace with messages containing pipes The first entry was written with a message "The pipe comes between o's: o|o", the second with a message "The pipe comes between o's and spaces: o | o"
See bug 286130. I don't think line breaks are an issue if we can ensure that '|' is not contained in messages. We likely need to do some escaping of '|' like you suggest for the following fields of a trace entry. - thread name - option path - message - throwable If we escape the pipes somehow then each you just need to read each entry string up to the next '|' char, even if there are line feeds in the middle. Correct? I'm not sure what the best option is for escaping '|'. Perhaps we should use the html escaping for '|' (|). Note that we already changed the format to version 1.1 for 3.6 in bug 286130 so any other changes here do not require a bump in format version.
Created attachment 158108 [details] possible patch for this problem. How about the following patch? It encodes any occurrences of | with the string Tom recommended (|). This is applied to only the thread name, option path, message, and any of the throwable text. I've also updated the junit testcase to verify this scenario (however it only checks the option-path and message).
Created attachment 158113 [details] updated patch Thanks Troy! Here is an updated patch. There was an issue if the | char was at the end of the string for decoding/encoding. Here is another implementation of encoding/decoding and updated testcase to test having multiple | chars and at the beginning and end of the string.
Great.
Patch released. (with small change to not use "this" to call the static method encodeText).
Created attachment 158860 [details] Proposed javadoc change
Comment on attachment 158860 [details] Proposed javadoc change The specific behavior for escaping pipes should be documented in the javadoc.
Comment on attachment 158860 [details] Proposed javadoc change Thanks, patch has been released.
