I would be happy to test but haven't looked at the writer implementations, so speedy would not be the effort.  But, it's a performance issue only...maybe...so no hurry anyway.

On Tue, Jan 12, 2016 at 11:30 AM, Gary Gregory <garydgregory@gmail.com> wrote:

If the reason to do this is performance, it should be proved by a benchmark...

Gary

On Jan 12, 2016 8:28 AM, "Gary Gregory" <garydgregory@gmail.com> wrote:

Maybe something like mdcStyle="this/that/future"?

This would also apply to the XML layout?

Gary

On Jan 12, 2016 8:26 AM, "Mikael Ståldal" <mikael.staldal@magine.com> wrote:
Ah yes, that's possible. It would be nice.

On Tue, Jan 12, 2016 at 5:24 PM, Ralph Goers <ralph.goers@dslextreme.com> wrote:
If there is a flag that causes the new structure to be generated then he would get the performance gain when it is enabled. The current structure would be generated when the flag is not set.

Ralph

On Jan 12, 2016, at 9:14 AM, Mikael Ståldal <mikael.staldal@magine.com> wrote:

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 <rcoe.javadev@gmail.com> 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 <mikael.staldal@magine.com> 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.


Perhaps GELFLayout would work better for you.

On Mon, Jan 4, 2016 at 10:00 PM, Gary Gregory <garydgregory@gmail.com> 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" <rcoe.javadev@gmail.com> 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 <garydgregory@gmail.com> 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" <rcoe.javadev@gmail.com> 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.




--
MagineTV

Mikael Ståldal
Senior software developer

Magine TV
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.   




--
MagineTV

Mikael Ståldal
Senior software developer

Magine TV
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.   




--
MagineTV

Mikael Ståldal
Senior software developer

Magine TV
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.