Is it possible to use a FallbackAppender to fall back to a recreated version of itself? If not, perhaps a sort of RecoverableAppender wrapper or something may be useful.
On 7 June 2017 at 07:41, Apache <[email protected]> wrote: > The reason managers were split from the appender sis because appender are > recreated during reconfiguration while managers are reused. > > 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]> > >> > > > -- Matt Sicker <[email protected]>
