Ceki,
what are the chances of changing this to include the date from the start of
logging for the
next release? I'd be happy to make the code changes myself even -- should be trivial.
It will
save a bunch of file renames for the CompositeRollingFileAppender -- or whatever name
is good for
the Daily + Size rolling appender combined.
I'd like your opinion on I thought I just had -- I could write a composite which
combines the
other two (only) or a composite which can do either rolling feature or both and thus
makes the
original two redudant/obsolete. Preference and reasons?
Thanks as always,
Kevin
Ceki Gülcü wrote:
> Kevin,
>
> Eeuuh - I'd go with a bad choice. I can't think of no vital interest whatsoever.
>Regards, Ceki
>
> At 23:32 25.06.2001 -0700, you wrote:
> >DailyRollingFileAppender starts by logging to "file.log" and
> >eventually renames that file to "file.log.YYYY-MM-DD" (as
> >appropriate to the timing) and begins logging to a fresh
> >version of "file.log". Why do this rather than start
> >logging to file "file.log.YYYY-MM-DD" in the first place so
> >that all files including the current file are date tagged?
> >Either this was an arbitrary design choice, or I'm not
> >seeing some vital importance to having the file currently
> >logged to always be the same -- I'm guessing the latter so
> >please enlighten me.
> >
> >Kevin
> >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
>
> --
> Ceki Gülcü
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
