Sometimes I have appenders that dont get log messages very often - usually
cause they set their thresholds to "error" or above. The
DailyRollingFileAppender doesnt work right with these classes cause the
files dont get considered for rollover unless a log event has occured -
sometimes days after the event. The behaviour I would like to see is for a
file to rollover on the hour - if there are any items and not to rollover if
there are no items.
Note that this problem is not fixed using the Roller class - what that does
is force a rollover "every so often". What I want is to "ping" the subAppend
method "every so often" so that it will periodically check whether it needs
to rollover or not.
I have some of my own Appenders and I implemented a public method called
"timeToRollover" in them. I have setup a java.util.Timer (which runs every
minute) and a java.util.TimerTask that calls this timeToRollover method of
its Appender (but the Appender is really one of my subclasses - so I can do
this easily). This way, I have a thread that pokes and prods my Appender
every minute to "ask" it to check if it should rollover.
However I cannot do this so straightforwardly with the
DailyRollingFileAppender class. I could have duplicated what the subAppend
method does (except to not log the LoggingEvent) except that the neccessary
members are private. I am wondering if calling subAppend with a "bogus"
LoggingEvent (constructed with all null objects) will do the trick for me?
Kinda like side-effect programming.
I was also considering just calling rollOver anyway as it has some code:
String datedFilename = fileName+sdf.format(now);
if (scheduledFilename.equals(datedFilename))
return;
that looks like it will almost but not quite "test" before rolling over. I
think that calling this will actually result in files that are rolled over
too soon. So a given hour may have entries scattered across 2 files. ??
Any ideas? Should we add a method named "checkTimeToRollover" to the
Appender interface!
----------------------- interlude
Concerning private members (my opinion): Using private as the default access
level for member variables and methods closes the door on many things
subclasses could do - usually these are things the original writer of the
class never envisioned at the time of writing but come to be a need later
on.
Presumably the writer of DailyRollingFileAppender never concieved of the
need for ensuring consistent rollovers. I think all Appenders seem to suffer
from this problem of not rollingover unles an event is logged. And now that
the need is there, I cannot implement via a subclass cause the superclass
(DailyRollingFileAppender) uses private members!
------------------------------------
Note: I cannot just go ahead an log "null" (or innocuous) events as some
Appenders have threshold of error - and the sign that these files are EMPTY
is used so I can see the system is running smoothly. Having these files
populated with a bunch of "null" events would be very annoying.
Mike Papper
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
