Serialization of exceptions about chronicle-logger

[peter-lawrey]

I think this is a reasonable approach.

Longer term, I would like to serialize an Exception in a text form which
allows deserialization, however can be read without the class which created
it.

On 10 March 2015 at 21:03, Alexandre Victoor [email protected]
wrote:

Hello
This ticket is related to the comments of former ticket 15
When a binary appender is used, an exception is serialized with serializer
"JDKZObjectSerializer". This implies that you cannot read logs if you do
not have in your classpath the exception classes that have been used by the
application that has generated the logs.
This forbid to use ChroniTail, ChroniCat and the other tools working as
standalone tools...
Also this almost forbid applications to refactor their exception classes.
Instead of serializing the exception itself, I think that the logger
should serialize an object containing two strings:

1. the exception message
2. the exception stack trace as a string

—
Reply to this email directly or view it on GitHub
#26.

[lburgazzoli]

It is reasonable for exceptions but it doesn't for other objects so if you call logger.info("got {}", obj, except) to a binary appender , exception will be always readable but obj won't unless you have it in the class-path. The simplest way to have an 'open' log is to use a TextAppendet which format the message and serialized exceptions as strings.

I can easily add an option to serialize exception as strings but as mentioned above, non simple objects require the class to be available, is that an acceptable limitation?

I can also add an option to chronicle to serialize objects without compression.

[alexvictoor]

Thanks for your responses
Is there any doc on how works a binary chronicle/appender vs a text one?
I have done a few tests and even when i just log a string, the binary appender is much faster than the text one. I do not get why? Compression is done by default?

[lburgazzoli]

Not at the moment but I will document the difference between binary and text as soon as possible.

The main difference is that binary use buffer.write(...) wich write bytes (i.e. 4 bit for an int) whereas text uses buffer.append(...) which write thing in a human readable form (similar to append strings); in addition the TextAppender need to format the message (i.e. the logback appender invokes ILoggingEvent.getFormattedMessage).

Yes at the moment compression is done by default, I will add an option to Chronicle V3 to disable it.

[alexvictoor]

Thanks!
much more clear now. I was not aware that I could use the Externalizable interface and did not know BytesMarshallable and DataValueClasses...
BTW next month I will do a talk at devoxx france and I will talk a little bit of openhft 👍

[lburgazzoli]

@alexvictoor can we close this issue ?