It is reasonable but I really dislike having to tell users they need to change their code to get rid of the new warnings.
Ralph > On Jun 4, 2017, at 9:48 AM, 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]> >> >> >>
