It seems OK to me. Ralph
> On Jun 3, 2017, at 6:45 PM, Matt Sicker <[email protected]> wrote: > > I like the type erasure allowing for easier BC idea for sure. > > On 3 June 2017 at 14:08, Gary Gregory <[email protected]> wrote: > >> 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 >>> >>> >>> >> > > > > -- > Matt Sicker <[email protected]>
