Gary, this really doesn’t make sense. Now If I do:
MapMessage<MapMessage, String> msg = new MapMessage<>(); msg.with(“count”, 5); msg.with(“amount”, 1.01); msg.with(“text”, “Hello”); Map<String, String> map = msg.getData(); I am going to get back a Map where all the values are Strings because getData() has cast them to Strings when building the unmodifiable map. If I do: MapMessage<MapMessage, Integer> msg = new MapMessage<>(); msg.with(“count”, 5); msg.with(“amount”, 1.01); msg.with(“text”, “Hello”); Map<String, Integer> map = msg.getData(); getData is going to throw an exception trying to convert “Hello” to an integer. If you are really going to implement it this way then the “with” methods should accept arbitrary values ONLY if the type specified was Object. It should never be allowed to assign data of different types to the Map if a concrete type has been specified. Ralph > On Jan 12, 2018, at 10:48 AM, Gary Gregory <garydgreg...@gmail.com> wrote: > > On Fri, Jan 12, 2018 at 10:47 AM, Gary Gregory <garydgreg...@gmail.com > <mailto:garydgreg...@gmail.com>> > wrote: > >> On Fri, Jan 12, 2018 at 12:33 AM, Ralph Goers <ralph.go...@dslextreme.com> >> wrote: >> >>> Then I don’t understand why you modified MapMessage to be >>> >>> public class MapMessage<M extends MapMessage<M, V>, V> >>> and the getData method returns has the signature >>> >>> public Map<String, V> getData() >>> >>> If you are putting arbitrary stuff in the Map then this signature is >>> wrong. >>> >> >> Hi Ralph: >> >> I think this is OK, just like with a HashMap. If you want to type a >> MessageMap/HashMap to a narrow value like an Integer or a Whatnot then you >> use that type for V. If you want to put mixed types then you use Object for >> V. >> > > So "MapMessage.put(String, String)" can stay as is and you can use a "with" > method for typed use cases. > > Gary > > >> Gary >> >>> >>> Ralph >>> >>> >>>> On Jan 11, 2018, at 11:29 PM, Gary Gregory <garydgreg...@gmail.com> >>> wrote: >>>> >>>> Hi Ralph, >>>> >>>> I will have to look at the generics in the morning but my requirement >>> from >>>> day one is that a MapMessage allow values of any type (String keys are >>>> fine.) where each value in a MapMessage can be of a different types. A >>>> specific Appender can decide what to do with the values. Having all >>> Strings >>>> as values would not be good for all of the use cases I have (JMS, JDBC, >>> and >>>> MongoDB.) JDBC should pass values down to its prepared statement with >>>> PreparedStatement.setObject(int,Object) for example. Same idea for >>> MongoDB. >>>> All this works now, which is nice. >>>> >>>> Gary >>>> >>>> On Thu, Jan 11, 2018 at 9:24 PM, Ralph Goers < >>> ralph.go...@dslextreme.com> >>>> wrote: >>>> >>>>> In looking at the history MapMessage only supported Strings until you >>>>> modified it last June. It appears to me you did it incorrectly. You >>> made >>>>> MapMessage generic but left the put and putAll methods as only >>> supporting >>>>> String values. I am not sure why you would have done that instead of >>> having >>>>> them use the same generic. It also seems to be a problem that you >>> added >>>>> all these with methods that allow arbitrary crap to be added to the Map >>>>> despite what the generic declaration says. >>>>> >>>>> Ralph >>>>> >>>>>> On Jan 11, 2018, at 4:28 PM, Gary Gregory <garydgreg...@gmail.com> >>>>> wrote: >>>>>> >>>>>> I can use one of the with() methods so no big deal. >>>>>> >>>>>> Gary >>>>>> >>>>>> On Thu, Jan 11, 2018 at 4:23 PM, Ralph Goers < >>> ralph.go...@dslextreme.com >>>>>> >>>>>> wrote: >>>>>> >>>>>>> I will have to look but as I recall I did that for a reason. >>>>>>> >>>>>>> Sent from my iPhone >>>>>>> >>>>>>>> On Jan 11, 2018, at 3:37 PM, Gary Gregory <garydgreg...@gmail.com> >>>>>>> wrote: >>>>>>>> >>>>>>>> It seems to me that: >>>>>>>> >>>>>>>> org.apache.logging.log4j.message.MapMessage.put(String, String) >>>>>>>> >>>>>>>> should really be: >>>>>>>> >>>>>>>> org.apache.logging.log4j.message.MapMessage.put(String, Object) >>>>>>>> >>>>>>>> Thoughts? >>>>>>>> >>>>>>>> Gary
