Re: [log4j2] org.apache.logging.log4j.message.MapMessage String vs. Object values.

2017-06-03 Thread Ralph Goers
It seems OK to me. Ralph > On Jun 3, 2017, at 6:45 PM, Matt Sicker wrote: > > I like the type erasure allowing for easier BC idea for sure. > > On 3 June 2017 at 14:08, Gary Gregory wrote: > >> On Fri, Jun 2, 2017 at 2:20 PM, Ralph Goers >> wrote: >> >>> From a backward compatibility point

Re: [log4j2] org.apache.logging.log4j.message.MapMessage String vs. Object values.

2017-06-03 Thread Matt Sicker
I like the type erasure allowing for easier BC idea for sure. On 3 June 2017 at 14:08, Gary Gregory wrote: > On Fri, Jun 2, 2017 at 2:20 PM, Ralph Goers > wrote: > > > From a backward compatibility point of view changing that would be a > > problem. Also, StructuredDataMessage extends MapMessag

Re: [log4j2] org.apache.logging.log4j.message.MapMessage String vs. Object values.

2017-06-03 Thread Gary Gregory
On Fri, Jun 2, 2017 at 2:20 PM, Ralph Goers wrote: > From a backward compatibility point of view changing that would be a > problem. Also, StructuredDataMessage extends MapMessage and expects a > String. That said, there must be a way to make it generic but have the > default be a String. For ex

Re: [log4j2] org.apache.logging.log4j.message.MapMessage String vs. Object values.

2017-06-03 Thread Gary Gregory
On Fri, Jun 2, 2017 at 2:20 PM, Ralph Goers wrote: > From a backward compatibility point of view changing that would be a > problem. Also, StructuredDataMessage extends MapMessage and expects a > String. That said, there must be a way to make it generic but have the > default be a String. For ex