Support for netty CompactObjectOutputStream / CompactObjectInputStream

[kawashirov]

Some projects use netty for network communication and use netty default ObjectEncoder & ObjectDecoder which is use CompactObjectOutputStream & CompactObjectInputStream which is based on Java ObjectOutputStream & ObjectInputStream but not compatible with it.

Can you please make support for netty serialization? It's look like there is no much differencies between this two codecs.

[tcalmant]

It seems to be possible to implement a reader for this kind of serialization, with a bit of work.
Could you provide sample files, serialized this way ?

[kawashirov]

For example, one app sends data using this encoding method:
00000071 05 75720000025B42ACF317F8060854E00200007870 00000058 1F8B0800000000000000636060486560CE49CC636660606062602BCE2F2D4A4E05711818D8CB528B8A33F341525A271958738BD33D53A0324076486501585D2A035B69716A1150EA3F10303046FD07009E25AC6854000000.
For now I know that 00000071 is 113, the length of next bytes to the end of message. I don't rly get, is this part of java protocol or not, but next bytes is header: 05 is seems to be version, not prefixed with magic number, next 75720000025B42ACF317F8060854E00200007870 seems to be header for byte[] object, next 00000058 is 88, the length of that array of bytes. And leftover 1F8B0800000000000000636060486560CE49CC636660606062602BCE2F2D4A4E05711818D8CB528B8A33F341525A271958738BD33D53A0324076486501585D2A035B69716A1150EA3F10303046FD07009E25AC6854000000 is contents (gzipped data because start with 1F8B but this is another story). It seems it doesn't differs much from original java encoding because contents is not real class. But app that I work with is only sending byte[] like this. And for now I use this trick (read length, read and skip header, read length again, read contents) to decode and encode data.

[tcalmant]

Status for the 0.6.1 round: this stays open, but it is not something I can
implement as it is.

Netty's framing has to be reproduced exactly, otherwise what reaches the
parser is garbage. What is on this issue is a truncated hex fragment and a
description of a workaround, which is not enough to write a decoder against:
it would fit that one message and break on the next.

What would unblock it:

• one or two complete captured messages, as files
• the Netty version that produced them
• what the decoded object is supposed to be, to assert against

With that, the work itself is not in the parser: it is a small layer that
strips the length prefix and restores the elided class descriptors, then
hands a standard ObjectOutputStream stream to the existing v1/v2/v3
loaders, next to the transparent gzip handling in javaobj/utils.py.

If anyone still has such a stream, please attach it and I will pick this up.