Sounds pretty reasonable to me. On 4 June 2017 at 11:48, Gary Gregory <[email protected]> wrote:
> 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]> > > > > > > > -- Matt Sicker <[email protected]>
