I think what Mikael meant is that Serializable is just a marker interface that does not provide any guidance on what methods to call on it to turn the result into bytes. Unless we want to use java serialization, and I presume one of the main reasons for creating a custom binary layout (other than performance) is to avoid java serialization and the associated security risks.
How should a custom binary layout turn the result of `toSerializable` into bytes without using java serialization? - may be the question that Mikael is trying to answer. Correct me if I'm wrong, Mikael. I think a custom binary layout should just return the bytes it produced itself. Either as a byte array or as a ByteBuffer. On Wed, Jan 17, 2018 at 12:23 AM, Ralph Goers <[email protected]> wrote: > I think MessageLayout is a special case as it only returns the message > portion of the LogEvent. Most Layouts return all of the LogEvent > attributes. Even so, you could have AbstractLayout<LogEventProxy> if you > wanted the serialized version of the LogEvent. It can also be anything else > that implements Serializable. > > Ralph > > > On Jan 16, 2018, at 8:06 AM, Remko Popma <[email protected]> wrote: > > > > Doesn't that depend on the generic type T of the Layout<T>? > > For example, MessageLayout extends AbstractLayout<Message> returns a > > Message instance. > > You could return a ByteBuffer, but generally for an efficient binary > layout > > I would look at the encode method instead. > > > > On Tue, Jan 16, 2018 at 11:45 PM, Mikael Ståldal <[email protected]> > wrote: > > > >> How is a binary layout (extending AbstractLayout) supposed to implement > >> the toSerializable method in the Layout interface? > >> > >> Why is that method there? > >> > >> > > >
