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 wrote:
>
> Hi All:
>
> I've completed all the clean up
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 wrote:
> The reason managers were split from the appender sis because appender are
> recreated
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 wrote:
>
> Hi All:
>
> I've completed all the clean ups I think were needed in the
> GenericMapMessageSimple b
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
On Sun, Jun 4, 2017 at 3:34 PM, Matt Sicker 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
should be p
Raw type warnings? In my experience, barely anyone even notices them let
alone fixes them. :/
On 4 June 2017 at 16:57, Ralph Goers 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,
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 wrote:
>
> Hi,
>
> I was about to merger the branch GenericMapMessageSimple when I realized
> something... Right now, all
Sounds pretty reasonable to me.
On 4 June 2017 at 11:48, Gary Gregory 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 impleme
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 bei
It seems OK to me.
Ralph
> On Jun 3, 2017, at 6:45 PM, Matt Sicker wrote:
>
> I like the type erasure allowing for easier BC idea for sure.
>
> On 3 June 2017 at 14:08, Gary Gregory wrote:
>
>> On Fri, Jun 2, 2017 at 2:20 PM, Ralph Goers
>> wrote:
>>
>>> From a backward compatibility point
I like the type erasure allowing for easier BC idea for sure.
On 3 June 2017 at 14:08, Gary Gregory wrote:
> On Fri, Jun 2, 2017 at 2:20 PM, Ralph Goers
> wrote:
>
> > From a backward compatibility point of view changing that would be a
> > problem. Also, StructuredDataMessage extends MapMessag
On Fri, Jun 2, 2017 at 2:20 PM, Ralph Goers
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 ex
On Fri, Jun 2, 2017 at 2:20 PM, Ralph Goers
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 ex
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
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 ty
15 matches
Mail list logo
