On Aug 2, 2007, at 1:16 AM, Cliff Burger wrote:
A file is not a good target for multiple users or threads, unless
you have some type of service in front of it. If you do, you have a
database server.
To be rhetorical: Is building this type of architecture (basically,
the IO handling of a DB server) into fileappender in scope of the
apache logger?
No, we don't want to attempt to do any file locking or other IO
synchronization. You slowly take incremental steps and find that you
have written a poorly-designed DB server. The author of the original
suggestion was concerned with file permissions or modes, not
synchronization. He possibly should have been concerned with
synchronization, but his problem description wasn't explicit whether
he was expecting his console app and webserver to overlap.
The original suggestion on log4php-dev was to add a chmod or umask
attribute to allow controlling the file mode or access control list.
The scenario described was of a console app run by an interactive
user account and a web server running under a more limited account
writing to the same log file. The author did not state whether he
anticipated that the operations could be simultaneous or whether the
console app might have been a web server configuration app that would
only run when the web server was down. If the console app was
intended to be run at the same time the webserver was running, then
the setup is unreliable and he needs to log to different log files or
use a different appender that is reliable under those conditions. We
do not need to add any new features to support usage that should be
avoided.
If the console app was a configuration app, then he could get in a
state where a log file created by the console app could be blocked
from being opened or appended to by the web server. log4net appears
to support that type of scenario with the securityContext element
where you could say all logging was done using a particular set of
credentials which would prevent the rights issue. log4j doesn't
provide anything along that line. The proposed enhancement for
log4php appears to be platform-dependent, but I don't know PHP that
well.
My thought is that the suggested PHP enhancement is not desirable
since it appears to be platform specific and encourages unsafe
behavior. I don't know enough about the securityContext element in
log4net to see if it might be a reasonable alternative.
