But I guess that you won't get any performance gain if we keep the old
structure besides the new one, since then both will be parsed.

On Tue, Jan 12, 2016 at 3:15 PM, Robin Coe <[email protected]> wrote:

> I agree that if it were changed there may be some compatibility issues.
> But, if it's doable, then introducing a new property could bridge the
> change.  Not saying it's doable, because I haven't looked, but a new
> property and a deprecation warning (in docs, I expect) would allow the
> change to happen.  Very preliminary data showed me that parsing 1000 events
> slowed my parser from < 500 ms (w/o contextMap) to 2000 ms when each event
> contained 2 contextMap entries, requiring the list of maps to be converted
> to a single map.  Not sure what the time would be to parse a multi-valued
> map, though, so I can't be sure of the overhead of walking the list wrapper.
>
> On Tue, Jan 12, 2016 at 6:05 AM, Mikael Ståldal <[email protected]
> > wrote:
>
>> I think that the current JSONLayout format is unfortunate, and I would
>> prefer to have it as you propose. But we cannot change it now since that
>> will break backwards compatibility.
>>
>> See: https://issues.apache.org/jira/browse/LOG4J2-623
>>
>> Perhaps GELFLayout would work better for you.
>>
>> On Mon, Jan 4, 2016 at 10:00 PM, Gary Gregory <[email protected]>
>> wrote:
>>
>>> The point I was trying to make is that you cannot describe what you are
>>> asking for with a generic XML schema, not sure about JSON schema, but the
>>> idea is the same. Since we use Jackson, that also means we use the same
>>> code to emit JSON and XML.
>>>
>>> Gary
>>> On Jan 4, 2016 12:25 PM, "Robin Coe" <[email protected]> wrote:
>>>
>>>> I can see that XML entities requires conforming to a schema but isn't
>>>> the writer implementation capable of wrapping the map entries when
>>>> required?  Seems like it's making the JSON representation more complex (and
>>>> less performant) at the cost of some wrapper code for the xml writer.
>>>>
>>>> On Mon, Jan 4, 2016 at 3:19 PM, Gary Gregory <[email protected]>
>>>> wrote:
>>>>
>>>>> Yes, that is because we can define this kind of structure with
>>>>> XML/JSON schema with ease.
>>>>>
>>>>> Gary
>>>>> On Jan 4, 2016 11:55 AM, "Robin Coe" <[email protected]> wrote:
>>>>>
>>>>>> I was trying to deserialize a log event written by the JSONLayout
>>>>>> appender, which uses Jackson.  I therefore also am using Jackson but with
>>>>>> the MrBeanModule, which is a POJO materializer.  After much difficulty 
>>>>>> with
>>>>>> Jackson throwing deserialization exceptions with the "contextMap" field, 
>>>>>> I
>>>>>> learned that the map is actually written out as a List of Maps (i.e.
>>>>>> List<Map<String,String>>.  I've included one such event here, with
>>>>>> unnecessary fields shortened:
>>>>>>
>>>>>>
>>>>>> {"timeMillis":...,"thread":"...","level":"OFF","loggerName":"...","message":"...","endOfBatch":false,"loggerFqcn":"...","contextMap":[{"key":"LOGROLL","value":"com.xxx.xxx.handler.event.FailoverHandler"},{"key":"ROUTINGKEY","value":"elasticsearch-rollover"}]}
>>>>>>
>>>>>> I'm curious why the contextMap is represented as the more complex
>>>>>> List of single entry Maps, as opposed to a single multi-valued Map?  So,
>>>>>> instead of something that looks like:
>>>>>>
>>>>>>
>>>>>> {"contextMap":[{"key":"key1"},{"value":"value1"},{"key":"key2"},{"value":"value2"},...]
>>>>>>
>>>>>> I would expect the much simpler (and easily parseable):
>>>>>>     {"contextMap":{"key1":"value1","key2":"value2",...}.
>>>>>>
>>>>>> Is this intended?
>>>>>>
>>>>>> Thanks,
>>>>>> Robin.
>>>>>>
>>>>>
>>>>
>>
>>
>> --
>> [image: MagineTV]
>>
>> *Mikael Ståldal*
>> Senior software developer
>>
>> *Magine TV*
>> [email protected]
>> Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com
>>
>> Privileged and/or Confidential Information may be contained in this
>> message. If you are not the addressee indicated in this message
>> (or responsible for delivery of the message to such a person), you may
>> not copy or deliver this message to anyone. In such case,
>> you should destroy this message and kindly notify the sender by reply
>> email.
>>
>
>


-- 
[image: MagineTV]

*Mikael Ståldal*
Senior software developer

*Magine TV*
[email protected]
Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com

Privileged and/or Confidential Information may be contained in this
message. If you are not the addressee indicated in this message
(or responsible for delivery of the message to such a person), you may not
copy or deliver this message to anyone. In such case,
you should destroy this message and kindly notify the sender by reply
email.

Reply via email to