Hi all,
As a relative newcomer to the Log4J package, let me say a well-done over
this. Seems to have covered everything I could have thought about in a
logging package.
However, I have to report this problem in, as one of the more important
features to me is the fail-stop property (I prefer the term fail-safe).
In this case, I received an uncaught exception while appending to a
RollingFileAppender. The exception was:
java.security.AccessControlException: access denied
(java.io.FilePermission /var/log/Keepalive.log.1 delete)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:272)
at
java.security.AccessController.checkPermission(AccessController.java:399)
at
java.lang.SecurityManager.checkPermission(SecurityManager.java:545)
at
java.lang.SecurityManager.checkDelete(SecurityManager.java:1005)
at java.io.File.delete(File.java:712)
at
org.apache.log4j.RollingFileAppender.rollOver(RollingFileAppender.java:125)
at
org.apache.log4j.RollingFileAppender.subAppend(RollingFileAppender.java:233)
at
org.apache.log4j.WriterAppender.append(WriterAppender.java:153)
at
org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:221)
at
org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:57)
at org.apache.log4j.Category.callAppenders(Category.java:198)
at org.apache.log4j.Category.forcedLog(Category.java:391)
at org.apache.log4j.Category.debug(Category.java:252)
at.....
I was using Log4J version 1.2alpha5 under Sun's JVM 1.3.1 on Solaris.
The cause of the problem was that I was actually running a client
towards Sun's J2EE reference server, and using the (almost) default
client.policy file for the permission settings. This file contains the
rather useful line:
permission java.io.FilePermission "<<ALL FILES>>", "read,write";
Great huh? Overwrite /etc/passwd, but don't delete your own files!
So, RollingFileAppender couldn't delete the last backup file when it
needed to rotate along one. OK, I had a problem, but I don't think the
exception should have made it back out to the user code.
I spent a little while trying to understand the way in which the
ErrorHandler mechanism actually gives Log4J its fail-stop behaviour. If
I get it correctly, this behaviour is mainly delegated to QuietWriter,
and called into use when an IOException is caught by the write() or
flush() methods, in which case WriterAppender.subAppend() is protected
from IOExceptions. Right?
The remaining calls to ErrorHandler.error() are made from *FileAppender.
While checking these, I noticed that DailyRollingFileAppender surrounds
its call to rollOver() with IOException catches, while
RollingFileAppender doesn't.
Anyway, while looking at this, and wondering why the compiler was
allowing IOException through for my case, I realised that I was actually
getting a RuntimeException rather than an IOException. And it struck me:
To be really fail-stop, doesn't Log4J *in general* need to be trapping
some (or perhaps all) RuntimeExceptions as well as the compiler-checked
exceptions such as IOException?
It seems to me that exceptions such as NullPointerException,
IllegalMonitorStateException, and SecurityException are all possible in
the light of programming errors in Log4J, or configuration errors on an
end-user part, and should be trapped as part of the fail-stop policy,
and at the outermost-possible part of Log4J - in this case, that appears
to be AppenderSkeleton.doAppend(), as Category.debug() etc don't have
nice access to an error handler.
This seems a big catch-all to be suggesting, so I've tried looking for
past discussions on the mailing list about this, but can't find anything
directly relevant. Has this been discussed before?
Cheers,
Mike
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
