Just sent you an error report generated by LVP when it failed to parse my JSON file.

I'm guessing the parsing error is happening beause one of the JSON properties contains encoded JSON, which is somehow confusing the parser. The encoded JSON is properly escaped, so it really should be handled the same as any other string value.

By the way, the reason I'm encoding JSON in a JSON object property is beause I need to log an API response that's sent as JSON. Unfortuntaely, your JSON parser only supports primitives, which kind of defeats the purpose of using JSON. Ideally, I could take the API response and store it as a proper JSON object within a property, instead of having to encode it to a string.

Hi AV,

I investigated this issue today and it is going to be more difficult to resolve than I initially expected.  We will not be able to produce a solution in the short term.

There are two main problems that we have at the moment.
1. The Parse Message command wants to identify other, similar messages in the log file.  Dealing with a variable like 'JSON' is too ambiguous.  For example, if multiple messages have a lot of differentiation, what would the column headings be?
2. There is a performance impact to parsing JSON (mainly from a memory perspective).  LogViewPlus processes messages when the file is parsed.  Right now, we don't to take the performance hit of parsing JSON unless we know the user was going to need this feature.

This is absolutely something that we will be investigating and adding in the future - it is just not something that we can quickly fix.

For the moment, the best solution I can suggest is to:
1. Manually identify the messages in the log file which are similar.
2. Export those log entries to a new log file.
3. Open the newly created log file.  Create a new parser configuration as needed.

You mentioned "very different objects each time".  Because of this, I don't think you will be able to easily solve your problem with a custom parser.  All LogViewPlus parsers require a conformity with the logging format.  If you have a lot of variability in your messages, this is going to be difficult.  Again - what would your column headers be?  Also, if your messages were more uniform, you wouldn't need a customer parser - the existing JSON parser would probably work fine.

Hope that helps,

Toby