>Maybe something like "Date", "Size", "ApplicationUptime", "RPCTrigger",
.. ?
RPCTrigger??
What you are really saying is that the new code needs to have enough
extension points that others could easily add new roll conditions. My
concern is in how to provide that functionality and get renaming and
deleting right.
>I believe that I have to explain this further. My idea is to split the
rolling
>into two parts:
>
> * rolling condition
> * file naming strategy
+1
>
>This should ideally deprecate the different rolling strategies and
their hideous
>behaviour by replacing it with a clear API and a configuration
semantic. This
>here:
+1 on the goal
>
><rollFileConfiguration>
> <rollFileCondition when="daily" />
> <rollFileNamingStrategy value="Date" /> </rollFileConfiguration>
>
>or this here (which is semantically the same, and would be just another
>implementation of the "condition" interface):
>
><rollFileConfiguration>
> <rollFileCondition month="*" day="*" hour="24" minute="*" />
> <rollFileNamingStrategy value="Date" /> </rollFileConfiguration>
>
+1 or even +2 on the time stamp condition.
I like the time stamp condition idea, but does that mean at hour 24 or
24 hours from starting time? I think it means hour 24, so what symbol
could we add to make it relative to starting time. Maybe a + so that
"+24" means 24 hours from when I started. Would a relative to start
time take away your requirement for a ApplicationUptime roll condition?
Questions about rollFileNamingStrategy.
Date makes sense, I assume that we would include the datePattern
somewhere as <rollFileNameByDatePattern = "yyMMdd"/> etc.
How do we incorporate that with a size rollover to achieve names similar
to what are produced now (or should be produced now) as
File.datetime1.1
File.datetime1.2
File.datetime2.1
File.datetime2.2
It seems to me that we would need to pair a naming strategy with each
roll strategy and indicate where that part of the name goes into the
final file name.
This brings me to File= parameter that has {Date} and {Size} etc. to
indicate where date and size patterns are to be inserted. (Likewise for
any other rolling condition.) If this idea is acceptable, then we do not
have to worry about the date pattern separator or preserve extension
etc. because it is all handled by the file pattern. The biggest
downside that I see at this time is scanning the File= parameter to
determine what goes where to create the directory search, but it should
be doable without too much unfixable code.
>Is much clearer than the old-fashioned thing:
Agreed
----------------------------------------------------------------------
Roy Chastain
