I would suggest looking at TCPSocketManager as it tries to recover from failures (although I recall seeing something saying there is a problem with the recovery losing a couple of events).
Ralph > On Jun 7, 2017, at 1:11 AM, Gary Gregory <[email protected]> wrote: > > Hi All: > > I've completed all the clean ups I think were needed in the > GenericMapMessageSimple branch (the no-new-class branch). > > I will merge to master tomorrow unless I hear otherwise. > > Then I can look at painful it would be to fix > https://issues.apache.org/jira/browse/LOG4J2-1934 > > Any advice there is appreciated. I thought the whole point of splitting > code into a manager from its appender was so that it could be reloaded from > first principles (from the builder data) but I do not see a simple way to > do that. Do we have an appender/manager pair that does that? > > My thought was that if the appender catches an Exception or detects that > the manager is stale, it throws it away and re-creates it based on the > builder data. > > Thank you, > Gary > > 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. :/ >> >> 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]> >>
