On Fri, Jun 2, 2017 at 2:20 PM, Ralph Goers <[email protected]> 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 example, you could create a GenericMapMessage > that expects <String, T> and has most or all of the logic from MapMessage > and then have MapMessage extend it as GenericMapMessage<String>. > Hi, I created two branches: GenericMapMessage adds a class called GenericMapMessage with MapMessage as the subclass. Clirr check passes GenericMapMessageSimple modifies MapMessage with the same new code that is in GenericMapMessage. Clirr check passes Since generics are erased, BC should not be an issue i neither case. The branch GenericMapMessageSimple is my preference since it does not add a new class. I opted to add "with" method instead of "put" methods since we already have a "with" method. No need to have both "put" and "with" methods IMO. Thoughts? Gary > Ralph > > > On Jun 2, 2017, at 2:04 PM, Gary Gregory <[email protected]> wrote: > > > > Hi All: > > > > We make a big deal that our logger APIs take Object messages instead of > > Strings, but over in org.apache.logging.log4j.message.MapMessage the > values > > are Strings, not Objects. > > > > Is that deliberate? > > > > That's proving to be a restriction for me... > > > > Any thoughts on allowing for the same kind of typing as in > > javax.jms.MapMessage? > > > > Thank you, > > > > Gary > > >
