Hi, I was about to merger the branch GenericMapMessageSimple when I realized something... Right now, all the code compiles and runs cleanly and the Clirr check passes.
But... Because of the new implementation declares MapMessage with generics, we do get compiler warnings about MapMessage not being used with generics. What I propose is that we declare a subclass called StringMapMessage which allows all call sites to be changed from MapMessage to StringMapMessage and eliminate compiler warnings. For more advanced use cases (like mine), I can use MapMessage with generics or declare my own subclass. I like MapMessage and a new StringMapMessage subclass better than the initial proposal of a new GenericMapMessage and MapMessage subclass. What do you guys think? Gary On Sat, Jun 3, 2017 at 9:21 PM, Ralph Goers <[email protected]> wrote: > 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]> > > >
