You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by Maple Wang <ma...@hotmail.com> on 2016/04/07 08:13:06 UTC

how to disable recursive check for appender in log4j2.5

Hi,

 

We are implementing a function with self-defined appender in log4j2.x, in
this appender, we forward LogEvent to other function modules,  and in those
function modules we also log some messages to this appender , so you must
understand that recursive call will happen sometimes. For current
implementation of log4j2.5, this kind of recursive call will be totally
blocked from appender, but this is not what we expect. Actually, we are
aware of this recursive call situation and we will handle it in appender by
ourselves to meet function requirement, it worked in log4j1.x, but it's not
working in  log4j2.x because of recursive call check for appender, is it
possible to disable it? Or at least to disable recursive call check for
specific appender.

 

Best regards.


Re: how to disable recursive check for appender in log4j2.5

Posted by Ralph Goers <ra...@dslextreme.com>.
It is possible that an appender might call some other component that does its own logging.  The problem is that it is too easy (or difficult to prevent) to have the configuration set up so that the logs from that component end up going back through the same appender.  For example, if you are using Hibernate in your application and want to be able to see those logs it is not possible to do that if your appender also calls Hibernate.

Ralph

> On Apr 7, 2016, at 7:04 AM, Matt Sicker <bo...@gmail.com> wrote:
> 
> It's generally recommended to use the StatusLogger implementation of Logger
> when logging inside log4j extensions like that. All log4j core components
> follow this idea.
> 
> On 7 April 2016 at 01:13, Maple Wang <ma...@hotmail.com> wrote:
> 
>> Hi,
>> 
>> 
>> 
>> We are implementing a function with self-defined appender in log4j2.x, in
>> this appender, we forward LogEvent to other function modules,  and in those
>> function modules we also log some messages to this appender , so you must
>> understand that recursive call will happen sometimes. For current
>> implementation of log4j2.5, this kind of recursive call will be totally
>> blocked from appender, but this is not what we expect. Actually, we are
>> aware of this recursive call situation and we will handle it in appender by
>> ourselves to meet function requirement, it worked in log4j1.x, but it's not
>> working in  log4j2.x because of recursive call check for appender, is it
>> possible to disable it? Or at least to disable recursive call check for
>> specific appender.
>> 
>> 
>> 
>> Best regards.
>> 
>> 
> 
> 
> -- 
> Matt Sicker <bo...@gmail.com>



---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org


Re: how to disable recursive check for appender in log4j2.5

Posted by Matt Sicker <bo...@gmail.com>.
It's generally recommended to use the StatusLogger implementation of Logger
when logging inside log4j extensions like that. All log4j core components
follow this idea.

On 7 April 2016 at 01:13, Maple Wang <ma...@hotmail.com> wrote:

> Hi,
>
>
>
> We are implementing a function with self-defined appender in log4j2.x, in
> this appender, we forward LogEvent to other function modules,  and in those
> function modules we also log some messages to this appender , so you must
> understand that recursive call will happen sometimes. For current
> implementation of log4j2.5, this kind of recursive call will be totally
> blocked from appender, but this is not what we expect. Actually, we are
> aware of this recursive call situation and we will handle it in appender by
> ourselves to meet function requirement, it worked in log4j1.x, but it's not
> working in  log4j2.x because of recursive call check for appender, is it
> possible to disable it? Or at least to disable recursive call check for
> specific appender.
>
>
>
> Best regards.
>
>


-- 
Matt Sicker <bo...@gmail.com>