I am a bit confused. At line 566 Log calls SLF4J so you will only end up back in Log4j 2 if you have made Log4j 2 the SLF4J implementation. That shouldn't cause any problems. Having Flume (or any other code such as Hibernate) attempt to log from inside an Appender is expected and would be detected and the logging call would be ignored if it is made on the same thread. However, if the work is being done on a second thread it would not appear to be a recursive call.
The simple solution for this is to configure a Logger for org.apache.flume and do not allow it to be routed to the FlumeAppender.
On Jun 10, 2013, at 3:31 PM, Edward Sargisson wrote:
> Hi all,
> I have discovered a defect in the way the Log4j2 embedded Flume agent works. As it is an interaction between the two code bases I am taking the liberty of making both teams aware of it by cross-posting to both dev lists.
> The summary is that, during a rollback, Flume's org.apache.flume.channel.file.Log calls the logging subsystem at line 566. This recursive call causes problems. There are other places where logging is called which cause similar problems.
> Details: https://issues.apache.org/jira/browse/LOG4J2-278