RE: DailyRollingFileAppender - why isn't rollOver protected
Thanks. I already told Ceki my opinion about log4j (I think it is really great and I love it). I would gladly check the file in jakarta-log4j and tell you if it solves my problem or any other feedback I have. However, I have to admit that I don't know how to find it. I never browsed the CVS before, the best I could find is: http://cvs.apache.org/viewcvs.cgi/jakarta-log4j/src/java/org/a pache/log4j/Da ilyRollingFileAppender.java but this claimed to be version 1.24 and suffer from all the problems I have in version 1.28. can you help me finding the right file. Hello Avner, Firstly apologise for the lengthy days delay in responding, I have been off work due to the dreaded flu that is hitting everyone here in Australia. Your question gave me an opportunity to explore more Ceki's new rollover area so that I can respond with at least some facts. From what I can tell by browsing the code, the relevant packages in the jakarta-log4j are org.apache.log4j.rolling and it's 'helper' sub-package. http://cvs.apache.org/viewcvs.cgi/jakarta-log4j/src/java/org/apache/log4j/ro lling/ Inside this main package is a brand new RollingFileAppender class, which you can use, and configure it with an implementation of a TriggeringPolicy, and a RollingPolicy. (This is the classic strategy pattern to allow you to plugin different ways of doing things). There will now be no need to sub-class the RollingAppender class, but just provide the RollingAppender with a custom TriggerPolicy or RollingPolicy as is required in your circumstances. A TriggeringPolicy is the 'when' of how the appender should roll, and the RollingPolicy is the 'how' the rolling actually occurs. You will notice that the rolling package has a TimeBasedRollingPolicy, and a SizedBasedTriggerPolicy class, these implement the classic configs of yester-year by Rolling based on time or by size. In your case you could probably choose to wrap one of these existing policies in your own class, first checking if anyone is reading the file, and if it meets at least those requirements, forwarding on the call to the wrapped Policy to do the work. Wrapping is usually my preferred way of doing things, but you may just prefer to sub-class, either works fine. I hope this helps you. regards, Paul Smith - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DailyRollingFileAppender - why isn't rollOver protected
Thanks. I already told Ceki my opinion about log4j (I think it is really great and I love it). I would gladly check the file in jakarta-log4j and tell you if it solves my problem or any other feedback I have. However, I have to admit that I don't know how to find it. I never browsed the CVS before, the best I could find is: http://cvs.apache.org/viewcvs.cgi/jakarta-log4j/src/java/org/apache/log4j/Da ilyRollingFileAppender.java but this claimed to be version 1.24 and suffer from all the problems I have in version 1.28. can you help me finding the right file. - Original Message - From: Paul Smith [EMAIL PROTECTED] To: 'Log4J Users List' [EMAIL PROTECTED] Sent: Sunday, June 29, 2003 11:27 PM Subject: RE: DailyRollingFileAppender - why isn't rollOver protected Hi Avner, You'll be pleased to know that Ceki has done a LOT of work on refactoring the Rolling appender stuff for Log4j 1.3 (not yet released). I can't give 100% guarantee that the new changes are what you are looking for, but suffice to say his new design should make it a lot easier to customize behaviour. Perhaps you could check out the jakarta-log4j module and see his new changes too see if it meets your needs? (we always love feedback! :) ) cheers, Paul Smith -Original Message- From: Avner BenHanoch [mailto:[EMAIL PROTECTED] Sent: Sunday, 29 June 2003 9:38 PM To: Log4J Users List Subject: DailyRollingFileAppender - why isn't rollOver protected I need to customize DailyRollingFileAppender, so rollOver will check if renaming the file is safe, before it renames it (because my application enable the user to view/query the log files). What I need is that in case the file is being read, don't rollOver, instead try again on the next time a record is appended. Unfortunately, this is not possible, because rollOver is not protected. To my opinion it should be protected, otherwise there is no real option to extend the class. If one want more details, then here they come: At first I wanted to do that by inheriting DailyRollingFileAppender and overriding subAppend. Then I noticed that it won't work (because subAppend schedules the time for next rollOver, even if current rollOver failed - so it won't happend on next time a record is appended). Then I wanted to override rollOver to raise a flag that will be inspected on next subAppend, to see if a rollOver is needed. Unfortunately, this is not possible, because rollOver is not protected. What I did to solve my problem is a little bit ugly. I copied DailyRollingFileAppender to my package without changes, changed its packagename accordingly, then I could extend it from a file in my package and called rollOver. this worked fine, but I think it is better if one could change rollOver or subAppend in DRFA, so it will be easier to extend the file. thanks, Avner - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: DailyRollingFileAppender - why isn't rollOver protected
Hi Avner, You'll be pleased to know that Ceki has done a LOT of work on refactoring the Rolling appender stuff for Log4j 1.3 (not yet released). I can't give 100% guarantee that the new changes are what you are looking for, but suffice to say his new design should make it a lot easier to customize behaviour. Perhaps you could check out the jakarta-log4j module and see his new changes too see if it meets your needs? (we always love feedback! :) ) cheers, Paul Smith -Original Message- From: Avner BenHanoch [mailto:[EMAIL PROTECTED] Sent: Sunday, 29 June 2003 9:38 PM To: Log4J Users List Subject: DailyRollingFileAppender - why isn't rollOver protected I need to customize DailyRollingFileAppender, so rollOver will check if renaming the file is safe, before it renames it (because my application enable the user to view/query the log files). What I need is that in case the file is being read, don't rollOver, instead try again on the next time a record is appended. Unfortunately, this is not possible, because rollOver is not protected. To my opinion it should be protected, otherwise there is no real option to extend the class. If one want more details, then here they come: At first I wanted to do that by inheriting DailyRollingFileAppender and overriding subAppend. Then I noticed that it won't work (because subAppend schedules the time for next rollOver, even if current rollOver failed - so it won't happend on next time a record is appended). Then I wanted to override rollOver to raise a flag that will be inspected on next subAppend, to see if a rollOver is needed. Unfortunately, this is not possible, because rollOver is not protected. What I did to solve my problem is a little bit ugly. I copied DailyRollingFileAppender to my package without changes, changed its packagename accordingly, then I could extend it from a file in my package and called rollOver. this worked fine, but I think it is better if one could change rollOver or subAppend in DRFA, so it will be easier to extend the file. thanks, Avner - 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]
