On Sep 23, 2011, at 2:07 AM, Dominik Psenner wrote:
>
> I've so far found this:
>
> http://logging.apache.org/log4j/companions/extras/apidocs/org/apache/log4j/r
> olling/package-tree.html
>
> Despite the fact that it is there in "extras", you're suggesting that it was
> abandoned? Why?
>
The
>Take a look at org.apache.log4j.rolling.RollingFileAppender which has
>pluggable rolling and file naming strategies.
>
>http://logging.apache.org/log4j/1.2/apidocs/index.html
>
>For a little ancient history, log4j 1.2 has two classes named
>RollingFileAppender, the original in org.apache.log4j and
Take a look at org.apache.log4j.rolling.RollingFileAppender which has pluggable
rolling and file naming strategies.
http://logging.apache.org/log4j/1.2/apidocs/index.html
For a little ancient history, log4j 1.2 has two classes named
RollingFileAppender, the original in org.apache.log4j and a ne
Sorry for the noise, but I have to correct myself. This here is the right link:
https://bitbucket.org/NachbarsLumpi/log4net-patches/src/tip/RFA-NG
The concentration is almost gone, I better go off to bed now. :-)
--
Dominik Psenner
## OpenPGP Key Signature #
# Key
> Thanks for the information. This means that today, specifically in the
> evening around 20°°, I'm going to try my best to come up with a
> "RollingFileAppenderNG" implementation that derives from FileAppender.
> Therefore the first layout of the RFA-NG will be much like the current RFA.
> We can
>My current plan is to dummy up a new RFA (configuration points) and
>write the XML doc for the configuration points and pass the result of
>that out for review and comments. We must be explicit about the
>semantics of the new configuration. We have already observed cases
>where I have not correc
>A sandbox is typically a branch or repository that is used to "play"
around with
>new code. I'll probably have to share that code through bitbucket as I
don't have
>the privileges to commit to the repository. Or can I get sufficient
privileges to
>commit to a branch in the ASF repository?
>
>Roy,
>-Original Message-
>From: Roy Chastain [mailto:r...@roychastain.org]
>Sent: Wednesday, September 21, 2011 12:14 AM
>To: Log4NET Dev
>Subject: RE: New RollingFileAppender semantics
>
>>Should I try to write down the API? It should be doable in a couple of
>hou
>Should I try to write down the API? It should be doable in a couple of hours
>and
>right now it looks like I have some free time tomorrow around 20°°-22°°. If so,
>is there somewhere a sandbox that I could use?
I am not sure what you are asking about a sand box etc, but anything that you
wish to
On 09/20/2011 05:06 PM, Roy Chastain wrote:
> I have already written code that could parse the old datepattern and
> determine where ? needed to go to do the file directory search. That
> code or a close relative can survive into the new model so, the
> directory search is still just a single pass
>>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.
>
>Since it's still our responsibility to rename files and the A
On 2011-09-20, Dominik Psenner wrote:
> 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
Stefan
>>Maybe something like "Date", "Size", "ApplicationUptime", "RPCTrigger",
>.. ?
>RPCTrigger??
Yea. I just came up with this idea. If you for example have a remoting
appender that finally writes with a rolling file appender, other
applications could trigger a file roll with an RPC call. The specifi
>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 an
>What you are suggesting is completely different from the current
>semantics.
>Until this email, I understood your example to be equivalent to a
>composite roll in the current implementation. In a composite roll, two
>different types of rolling take place. One on the date/time boundary
>and one o
Grouping the properties that affect the rolling strategy and
separating
them from the others makes sense to me.
>>
>>> It may be even a nice to implement it like that. This opens ways to
>>> something like this:
>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>You realize you are going d
Sorry, I have a typo there with a misplaced "not".. This:
>In my example, the roll file should be done daily and only if the file is
>not bigger than 5MB.
should be read as:
In my example, the roll file should be done daily and only if the file is
bigger than 5MB.
Sorry
>>> Grouping the properties that affect the rolling strategy and separating
>>> them from the others makes sense to me.
>
>> It may be even a nice to implement it like that. This opens ways to
>> something like this:
>
>>
>>
>>
>>
>>
>>
>
>You realize you are going down the road o
On 2011-09-19, Dominik Psenner wrote:
>>>
>>>
>>>
>>>
>>>
>>>
>> Grouping the properties that affect the rolling strategy and separating
>> them from the others makes sense to me.
> It may be even a nice to implement it like that. This opens ways to
> something like this:
>
>
>
>
>>
>>
>>
>>
>>
>>
>
> Grouping the properties that affect the rolling strategy and separating
> them from the others makes sense to me.
It may be even a nice to implement it like that. This opens ways to
something like this:
But I don't know if that really fits into the "
On 2011-09-19, Dominik Psenner wrote:
>> 3) - Any date portion in a file name be prefixed with a . as if it were
>> an extension.
> +1, but one should be able to change the "spacer" character. "." is a
> nuisance to regex parse a logfile, where "-" is tangentially easier.
+1 for an option to rep
On 2011-09-18, Roy Chastain wrote:
> After having spent two weekends looking at and playing with the code, I
> have decided that I do not have clear understanding of my target.
Poor you.
> Given that it appears that I am going to break the internal contract for
> RFA and the ambiguity in the cur
>> Should it be modifiable? I'm unsure.
It would be easier to code if it were always > 0, but there is a nicety
to having it negative when only a few iterations of the file are being
kept.
That said, I would have no problem removing it as a configuration
parameter.
>>+1, but one should be able to
>Given that it appears that I am going to break the internal contract for
>RFA and the ambiguity in the current implementation it appears that we
>should create a new RFA. (Perhaps called RollingFileAppender2??) with a
>clear definition of its semantics.
I expected this and favourite the rewrite
The current implementation of RFA allows configurations that are not
meaningful and have non-intuitive semantics.
Some of the issues come from the fact that the File parameter does not
have to have a file portion when there is a datePattern.
Example config from a bug report
This configuration
25 matches
Mail list logo
