On Sun, Jun 4, 2017 at 3:34 PM, Matt Sicker <[email protected]> wrote:
> Raw type warnings? In my experience, barely anyone even notices them let > alone fixes them. :/ > Right, warnings like (if you have them turned on, I do in Eclipse): "MapMessage is a raw type. References to generic type MapMessage<M,V> should be parameterized" Gary > > On 4 June 2017 at 16:57, Ralph Goers <[email protected]> wrote: > > > 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]> > > >> > > >> > > >> > > > > > > > > > -- > Matt Sicker <[email protected]> >
