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]>
