Tried to remove Log4jServletFilter reference to avoid "GC overhead limit exceeded", but still happens

At one point, I had changed my webapp's web.xml to reference the "Log4jServletFilter", but I since decided I didn't need to use that, and I was also seeing my app dying with stacktraces like the following: -- org.apache.cxf.interceptor.Fault: GC overhead limit exceeded at

What happens if I do NOT add the listener and filter in a servlet 2.5 webapp?

I'm looking at running a webapp in a version of WebLogic that appears to only support (at maximum) the Servlet 2.5 spec. The Log4j2 docs talk about using Log4j2 in a Servlet 2.5 container, at https://logging.apache.org/log4j/2.x/manual/webapp.html#Servlet-2.5 . This page says the following:

RE: Getting Could not find root logger information but I don't see why

-Original Message- From: KARR, DAVID (ATTSI) Sent: Wednesday, May 25, 2011 6:28 PM To: log4j-user@logging.apache.org Subject: Getting Could not find root logger information but I don't see why Using log4j 1.2.16 in WebLogic 10.3.2. While my app is starting up, I'm seeing

RE: Getting Could not find root logger information but I don't see why

in the webapp. Jake On Thu, 26 May 2011 01:27:42 +  KARR, DAVID (ATTSI) dk0...@att.com wrote: Using log4j 1.2.16 in WebLogic 10.3.2. While my app is starting up, I'm seeing the following message: Log4JInitServlet is initializing log4j Initializing log4j with: ...\my.ear\my.war\WEB-INF

RE: Getting Could not find root logger information but I don't see why

-Original Message- From: Jacob Kjome [mailto:h...@visi.com] Sent: Thursday, May 26, 2011 2:15 PM To: Log4J Users List Subject: Re: Getting Could not find root logger information but I don't see why Due to some other constraints, I appear to be forced to have my log4j.jar at

Getting Could not find root logger information but I don't see why

Using log4j 1.2.16 in WebLogic 10.3.2. While my app is starting up, I'm seeing the following message: Log4JInitServlet is initializing log4j Initializing log4j with: ...\my.ear\my.war\WEB-INF/log4j.xml log4j: Could not find root logger information. Is this OK? This is the log4j.xml file it's

RE: Re: Rehashing question about consequences of using configureAndWatch in a servlet

consequences of using configureAndWatch in a servlet Karr, David wrote: snip I would guess the way to rectify this would be to write your own loop in a thread that watches the log4j.xml file, with a timeout on each iteration, which checks a static flag that could be set

Rehashing question about consequences of using configureAndWatch in a servlet

I've googled the many discussions about the impact of using configureAndWatch() in a servlet. The Log4J FAQ says it is unsafe to use this in a J2EE application because of the nature of how this works. Discussion about this has been going on for a very long time (in internet time). I'd like to

RE: Missing log file entries

are maintaining in the backup. I will change the file size as you suggest, can you recommend a comfortable file size? -Original Message- From: Karr, David [mailto:[EMAIL PROTECTED] Sent: Thursday, 15 September 2005 12:12 AM To: Log4J Users List Subject: RE: Missing log file entries

RE: Missing log file entries

When you say that you're losing log messages, do you mean that you appear to be missing log files, or are you simply missing log messages within log files? By missing log files, do you see things like ..log.1, ..log.3, and ..log.4, where ..log.2 is missing? If that's the case, are you trying to

RE: V1.2.8: RollingFileAppender sometimes loses files when logging across Storage Area Network (SAN)

: Karr, David I wrote about this a few weeks ago, but I've since gotten more specific information about this problem. We have a situation where we're using the RollingFileAppender, and writing to log files on a Storage Area Network (SAN). We have two hosts, clustered with Microsoft

V1.2.8: RollingFileAppender sometimes loses files when logging across Storage Area Network (SAN)

I wrote about this a few weeks ago, but I've since gotten more specific information about this problem. We have a situation where we're using the RollingFileAppender, and writing to log files on a Storage Area Network (SAN). We have two hosts, clustered with Microsoft Clustering, such that only

V1.2.8: RollingFileAppender missing log file numbers?

We're seeing an odd problem with the RollingFileAppender, perhaps when we're pushing it pretty hard. At the end of the day sometimes we look at the directory where the log files are stored, and it appears that some of the log file numbers are missing. It isn't just that it wrote it out with the

Log4j1.2.8: What would cause DRFA to only occassionally actually write to the file, even with no buffering, and immediate flush?

I have a weird situation with a DailyRollingFileAppender. I'm finding that the code that is writing with this appender is only occassionally actually writing to the file. Just before doing the write, I forced the appender to use unbuffered io, and immediate flush (which is probably redundant).