Hi!

I've started playing around with building custom extensions, even though I'm not exactly a coder, so it's a bit stabbing around in the dark

Since this particular issue I'm approaching has rather long / complex message parts, my goal is to improve the message as it is displayed in the Log Entry Box (bottom right). I was able to use a post processor to massage the data into a shape, that can be handled better by the JSON pretty printer, however, I had to modify LogEntry.OriginalLogEntry for this.

However, Ideally I'd like to keep the original log entry as it is, so that I'm able to copy out log lines for reference.
(i.e. I would like to benefit from the high readability of the pretty printed entries for my own analysis, but when opening bugs, I can easily clip the original log entries as they were logged, to avoid arguments with developers )

In short, is it possible to keep the cake and eat it too?

Hi Zoltan,

As you have discovered, the OriginalLogEntry is used in the Log Entry Box and also copied to the clipboard on demand.  It is not currently possible to separate these activities into different fields.

You mentioned that you are trying to massage the data so it can be "handled better by the JSON pretty printer".  What exactly are you trying to do?  Maybe we can improve the pretty printer on our end?

Hope that helps,

Toby

Hi Toby,

thanks for the follow-up. For now I can live with this limitation, it's not that bad.

I have to work with several different types of really messy data (in the same logfile), and with a lot of work in post-processing some of it can be reformatted into JSON (but unfortunately, nothing straightforward, that could be easily fixed in the pretty printer).
Then I rely on the built-in JSON pretty-print to make the processed data much more readable.
I've attached the testing sample I'm using currently, as well as the same after my post processing.
The cases in sample are all addressed, but it does not cover yet every case I'll want to address eventually.

I could see two potential "improvements" here, that my use-case could benefit from:
- separate Log entry Box content from OriginalLogEntry. I think this would only need to happen when actually displaying content in the box, so not to keep everything twice in memory.
- make pretty printing extendable, so that custom pretty printers could be defined as plugins.

One tiny cosmetic issue with the pretty printer, however, for very long JSON's the syntax highlighting seems to give up (the entire log entry, although formatted correctly as JSON, is simply black text) - the "afterPostProcessing" file should have a couple of examples of what I mean - use it with JSON pretty print.

I'm running 2.6.1

Hi Zoltan,

Thanks for the feedback.

The logs are indeed information dense.  I can understand now why you would want more control over the information display. 

I don't think it will be feasible for us to provide another field for the message display.  I can see why this may seem like a simple change, but it would introduce a number of ambiguous scenarios around which field should be used.

We do have plans to make pretty printing extensible.  At the moment, this is a lower priority work item for us, but we will be revisiting the Common library in August, so we may be able to prioritise this work then.

I have noticed the issue with the pretty printer 'giving up' as well.  We are actually making big technical changes to the Log Entry Box in the current release, but are working to maintain the same behaviour.  Pretty printing will be reviewed in the next release.

There was one item on our list which might make managing your log entries a bit easier.  Tomorrow we should be releasing v2.6.2 which adds the 'Pretty Print' command to the Log Entry Grid.  This command will change the pretty print type of all selected log entries.



It is a small change, but I hope it helps.

Thanks again,

Toby

Hi Zoltan,

Just a quick update to let you know that the 2.6.2 BETA release is now available.

Thanks,

Toby