Hi Ankit -----Original Message----- From: Ankit Agarwal [mailto:ankit_agarwal@...] Sent: Tuesday, April 11, 2017 12:28 PM To: Tomcat Users List Subject: Re: Using Log4J2 2.8 (via the 1.2 API Bridge) for Tomcat8 Internal Logging - RollingFileAppender does not (cannot?) create new Log File
> Hi Cris, > > 1. No worries. All thoughts and questions are welcome > because it helps me think too :) OK good. I'm still learning about this also. :-) Just a friendly FYI, it is considered polite and in "good form" to intersperse your comments within the message segments to which they apply in your reply. That way those reading can easily maintain the context of the conversation in their minds. IOW, please don't "top post". :-) > 2. You can replace the java.utils.logging entirely with > Log4J in Tomcat. See the link I posted in my very first > email. The Tomcat documentation provides the steps. I knew it was possible, but I have not done that and don't know what the restrictions and gotchas are. > The only problem is that Tomcat only supports the Log4J > 1.x API. It doesn't natively support Log4J2 so we have > to use the 1.x -> 2.x Bridge and some things do not work. OK, can you get it basically working with the older Log4J instead, without the fancy stuff, just to investigate? Also, I don't know the interface between Tomcat/Log4J. I would have guessed that Log4J would need to conform to the Apache Commons Logging API, not the other way around. But again, I'm new to this. > E.g., I've found that the bridge does not support the > "Delete" directive within the "DefaultRolloverStrategy", > hence I have to delete the old zipped Tomcat logs with a > script myself - More likely this is because "Delete" is a > Log4J2 construct that Tomcat doesn't know about yet I'm > replacing the internal logging of Tomcat so, e.g., the > catalina log files and the localhost log files are written > by Log4J instead of the standard java.util.logging Log4J2 > works great within the WARs I deploy. Sorry, I'm gonna have to plead ignorance here. If Tomcat is delegating the responsibility of logging to Log4J, then why would Tomcat need to know anything about a delete operation, since Log4J is "handling the details"? Is there any way you could simplify your configuration to experiment, then add complexity in stages to see where it breaks down? IOW, start simple, get that working, add another option, and repeat? You might notice something during the process. > 3. The problem is that, for me when the first log-able event > occurs after the old log file is zipped, a new log file is > not created by the Tomcat Log4J. Instead nothing is logged > and operations just fail. E.g., once the old log file has > been zipped, if I try to deploy a new WAR, it just fails > because there is no place to log messages (since the new log > file was not created). I know this may sound like a "catch-22 situation", but what, if any, error messages are you getting? Is there a stack trace? I see that you have a Console appender configured that might be able to display errors. I wonder if that can be used to display errors from within the logging mechanism itself. > Once I restart Tomcat, everything works fine. It seems > that the Tomcat Log4J only rolls over to a new file (i.e., > creates it) on startup and not while its running. -- Cris Berneburg CACI Lead Software Engineer
