How the Log4J Viewer works
Language: Pure Java Script
UI Library: YUI
Architecture: 100% Client Side
Typically log files may contain thousands of lines and can be quite large. This is why the log4j viewer was designed to handle all processing on the client side so there is not client-server interaction at all. Another reason is security issues. Since log files might contain confidential information, users prefer not to send logging information across the network.
There is no safe way to parse a log4j file according to its pattern. This is a kind of reverse engineering which is not possible.
Consider the following example:
Log pattern = “%t %m%n”
This means that each line will contain the thread name a white space and the message followed by a new line.
Now, say we have a message where
thread name = “worker 1” and message = “hello world”
The result will be “worker 1 hello world“.
But the parser won’t know where the thread name ends and where the message starts. It could be any of the following combinations:
“worker“, “1 hello world”
“worker 1“, “hello world”
“worker 1 hello“, “world”
So as you can see the main limitations are using pattern attributes that contain white spaces in them. So here is the list of limitations that might cause log4j viewer to work improperly:
- Message (%m) must be at the end of line
- Pattern must end with a new line break (%n)
- Multi line messages are not supported
- Attributes that might contain spaces: for example (%t) are problematic. You can use them if they don’t contain spaces (like thread names without white spaces) but if the log line will have an extra white space it will probably mess up the output table.
- Attributes that might be in the pattern but don’t always appear in the log: %x, %X usually work but might cause problems.
This seems like a long list of limitations but the log4j viewer does cover most common log4j cases.
Developed by: Shlomo Schwarcz