Hi Ceki,
The problem is that it is the application that crashes but _not_ due to
log4j. We have lot of info/warn/error statements in probably each and
every class. But when the appplication crashes for some reason, the log
file does not have the recent stack trace before the application died,
Hello Krishna,
If your application runs out of memory at an arbitrary point in code,
log4j will not be invoked, and cannot log. However, you also seem to
imply that log4j is somehow responsible for the runtime exception. In
that case, could you please be more specific?
Suresh Krishna wrote:
Hi,
Hi,
We are using the the log4j for our applications. Recently we have come
to a blocking point that, the log4j does not log the exceptions or what
happened to the log file. Our application may crash with the *out of
memory error* or some *runtime exception*. In both the cases the log4j
does n
Sorted out.
Didnt call proper loader.
thanks
rs.K
nani2ratna wrote:
>
> Hi,
>
> I used log4j earlier and setit up in my windows machine 2 years back.
> Now I am using Opensuse. I wrote one class using eclipse.
> I put log4j.jar and commons.logging in buildpath.
> the class is like this
>
> pa
A common reason for not rolling over is that more than one appender instance
write to the same file, i.e. more than one file handle are open on the same
physical file.
Heri
-Ursprüngliche Nachricht-
Von: DOUTCH GARETH-GDO003 [mailto:gareth.dou...@motorola.com]
Gesendet: Montag, 29. Jun
Hi,
I used log4j earlier and setit up in my windows machine 2 years back.
Now I am using Opensuse. I wrote one class using eclipse.
I put log4j.jar and commons.logging in buildpath.
the class is like this
package log4jtest;
import java.io.FileInputStream;
import java.io.IOException;
import java
Hi there,
I have a number of machines where my RollingFileAppenders are not
rolling over, resulting in huge log files. Is there any particular cause
of this that I might be able to fix / avoid / workaround?
Cheers,
Gareth
