logging-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mikael Ståldal <mi...@apache.org>
Subject Re: [Log4j] Binary layout
Date Tue, 16 Jan 2018 21:25:32 GMT
I am experimenting with an Avro layout:
https://github.com/apache/logging-log4j-plugins/tree/avro-layout

It happens to be the case that the generated Avro value class implements 
Serializable, but is it appropriate to return that? Or should it return 
null? What if you want to make another binary layout, and no such 
Serializable class exist?

Maybe the Layout.toSerializable method should be documented to allow 
null return, and all call sites adapted to handle that it returns null 
(unless they assume a specific layout)?


On 2018-01-16 17:35, Ralph Goers wrote:
> Well, in looking at the various uses of that method I am a bit confused.
> 1. The JMSAppender will use Java serialization if it isn’t a MapMessage or a String.
> 2. CassandraManager uses some sort of TypeConverter to convert the Serializable - but
it only seems to handle a limited set of types. For example, using a LogEventProxy will result
in a null value being inserted.
> 3. NoSQLDatabaseManager only uses the serializable form if it is a MapMessage.
> 4. What JdbcDatabaseManager does seems to depend on what the column type is.
> 
> Those are pretty much the only usages I have seen. So what should be done depends on
how it would apply to any one of those cases. I suspect you are correct Remko, and that it
should just return the byte array.
> 
> Ralph
> 
>> On Jan 16, 2018, at 8:38 AM, Remko Popma <remko.popma@gmail.com> wrote:
>>
>> 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 <ralph.goers@dslextreme.com>
>> 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 <remko.popma@gmail.com> 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 <mikes@apache.org>
>>> wrote:
>>>>
>>>>> How is a binary layout (extending AbstractLayout) supposed to implement
>>>>> the toSerializable method in the Layout interface?
>>>>>
>>>>> Why is that method there?
>>>>>
>>>>>
>>>
>>>
>>>
> 
> 


Mime
View raw message